ros1_bridge package from ros1_bridge repo

ros1_bridge

Package Summary

Tags No category tags.
Version 0.8.2
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/ros1_bridge.git
VCS Type git
VCS Version eloquent
Last Updated 2020-01-17
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

A simple bridge between ROS 1 and ROS 2

Additional Links

No additional links.

Maintainers

  • Dirk Thomas

Authors

No additional authors.

Bridge communication between ROS 1 and ROS 2

This package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.

The bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed. Because of this its support is limited to only the message/service types available at compile time of the bridge. The bridge provided with the prebuilt ROS 2 binaries includes support for common ROS interfaces (messages/services), such as the interface packages listed in the ros2/common_interfaces repository and tf2_msgs. See the documentation for more details on how ROS 1 and ROS 2 interfaces are associated with each other. If you would like to use a bridge with other interfaces (including your own custom types), you will have to build the bridge from source (instructions below), after building and sourcing your custom types in separate ROS 1 and ROS 2 workspaces. See the documentation for an example setup.

For efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge. Note that before rostopic echo would work with bridged topics, a subscriber must already exist, in order for echo to determine the message type and then to create its own subscriber. You can use the --bridge-all-2to1-topics option to bridge all ROS 2 topics to ROS 1 so that tools such as rostopic list and rqt will see the topics even if there are no matching ROS 1 subscribers. Run ros2 run ros1_bridge dynamic_bridge -- --help for more options.

Prerequisites

In order to run the bridge you need to either:

  • get prebuilt binaries or
  • build the bridge as well as the other ROS 2 packages from source.

After that you can run both examples described below.

For all examples you need to source the environment of the install space where the bridge was built or unpacked to. Additionally you will need to either source the ROS 1 environment or at least set the ROS_MASTER_URI and run a roscore.

The following ROS 1 packages are required to build and use the bridge: * catkin * roscpp * roslaunch (for roscore executable) * rosmsg * std_msgs * as well as the Python package rospkg

To run the following examples you will also need these ROS 1 packages: * rosbash (for rosrun executable) * roscpp_tutorials * rospy_tutorials * rostopic * rqt_image_view

Building the bridge from source

Before continuing you should have the prerequisites for building ROS 2 from source installed following these instructions.

In the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case. If you run into trouble first make sure you have at least version 1.11.16 of ros_comm and rosbag.

The bridge uses pkg-config to find ROS 1 packages. ROS 2 packages are found through CMake using find_package(). Therefore the CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages.

Here are the steps for Linux and OSX.

You should first build everything but the ROS 1 bridge with normal colcon arguments. We don't recommend having your ROS 1 environment sourced during this step as it can add other libraries to the path.

colcon build --symlink-install --packages-skip ros1_bridge

Next you need to source the ROS 1 environment, for Linux and ROS Melodic that would be:

source /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash

The bridge will be built with support for any message/service packages that are on your path and have an associated mapping between ROS 1 and ROS 2. Therefore you must add any ROS 1 or ROS 2 workspaces that have message/service packages that you want to be bridged to your path before building the bridge. This can be done by adding explicit dependencies on the message/service packages to the package.xml of the bridge, so that colcon will add them to the path before it builds the bridge. Alternatively you can do it manually by sourcing the relevant workspaces yourself, e.g.:

# You have already sourced your ROS installation.
# Source your ROS 2 installation:
. <install-space-with-ros2>/local_setup.bash
# And if you have a ROS 1 overlay workspace, something like:
# . <install-space-to-ros1-overlay-ws>/setup.bash
# And if you have a ROS 2 overlay workspace, something like:
# . <install-space-to-ros2-overlay-ws>/local_setup.bash

Then build just the ROS 1 bridge:

colcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure

Note: If you are building on a memory constrained system you might want to limit the number of parallel jobs by setting e.g. the environment variable MAKEFLAGS=-j1.

Example 1: run the bridge and the example talker and listener

The talker and listener can be either a ROS 1 or a ROS 2 node. The bridge will pass the message along transparently.

Note: When you are running these demos make sure to only source the indicated workspaces. You will get errors from most tools if they have both workspaces in their environment.

Example 1a: ROS 1 talker and ROS 2 listener

First we start a ROS 1 roscore:

# Shell A (ROS 1 only):
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


Then we start the dynamic bridge which will watch the available ROS 1 and ROS 2 topics. Once a matching topic has been detected it starts to bridge the messages on this topic.

# Shell B (ROS 1 + ROS 2):
# Source ROS 1 first:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
# Source ROS 2 next:
. <install-space-with-bridge>/setup.bash
# For example:
# . /opt/ros/dashing/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

The program will start outputting the currently available topics in ROS 1 and ROS 2 in a regular interval.


Now we start the ROS 1 talker.

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun rospy_tutorials talker

The ROS 1 node will start printing the published messages to the console.


Now we start the ROS 2 listener from the demo_nodes_cpp ROS 2 package.

# Shell D:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_cpp listener

The ROS 2 node will start printing the received messages to the console.

When looking at the output in shell B there will be a line stating that the bridge for this topic has been created:

created 1to2 bridge for topic '/chatter' with ROS 1 type 'std_msgs/String' and ROS 2 type 'std_msgs/String'

At the end stop all programs with Ctrl-C. Once you stop either the talker or the listener in shell B a line will be stating that the bridge has been torn down:

removed 1to2 bridge for topic '/chatter'

Note: When the bridge is run using the default ROS 2 middleware implementation, which uses Fast RTPS, it does not always remove bridges instantly. See https://github.com/ros2/ros1_bridge/issues/38.

The screenshot shows all the shell windows and their expected content:

ROS 1 talker and ROS 2 listener

Example 1b: ROS 2 talker and ROS 1 listener

The steps are very similar to the previous example and therefore only the commands are described.

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 2 talker from the demo_nodes_py ROS 2 package.

# Shell C:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_py talker


Now we start the ROS 1 listener.

# Shell D:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun roscpp_tutorials listener

Example 2: run the bridge and exchange images

The second example will demonstrate the bridge passing along bigger and more complicated messages. A ROS 2 node is publishing images retrieved from a camera and on the ROS 1 side we use rqt_image_view to render the images in a GUI. And a ROS 1 publisher can send a message to toggle an option in the ROS 2 node.

First we start a ROS 1 roscore and the bridge:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <workspace-with-bridge>/install/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 1 GUI:

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rqt_image_view /image

--

Now we start the ROS 2 image publisher from the image_tools ROS 2 package:

# Shell D:
. <workspace-with-ros2>/install/setup.bash
ros2 run image_tools cam2image

You should see the current images in rqt_image_view which are coming from the ROS 2 node cam2image and are being passed along by the bridge.

--

To exercise the bridge in the opposite direction at the same time you can publish a message to the ROS 2 node from ROS 1. By publishing either true or false to the flip_image topic, the camera node will conditionally flip the image before sending it. You can either use the Message Publisher plugin in rqt to publish a std_msgs/Bool message on the topic flip_image, or run one of the two following rostopic commands:

# Shell E:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: true}"
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: false}"

The screenshot shows all the shell windows and their expected content (it was taken when Indigo was supported - you should use Melodic):

ROS 2 camera and ROS 1 rqt

Example 3: run the bridge for AddTwoInts service

In this example we will bridge a service TwoInts from ros/roscpp_tutorials and AddTwoInts from ros2/roscpp_examples.

While building, ros1_bridge looks for all installed ROS and ROS2 services. Found services are matched by comparing package name, service name and fields in a request and a response. If all names are the same in ROS and ROS2 service, the bridge will be created. It is also possible to pair services manually by creating a yaml file that will include names of corresponding services. You can find more information here.

So to make this example work, please make sure that the roscpp_tutorials package is installed on your system and the environment is set up correctly while you build ros1_bridge.

Launch ROS master

# Shell A:
. <ros-install-dir>/setup.bash
roscore -p 11311

Launch dynamic_bridge:

# Shell B:
. <ros-install-dir>/setup.bash
. <ros2-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

Launch TwoInts server:

# Shell C:
. <ros-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
rosrun roscpp_tutorials add_two_ints_server

Launch AddTwoInts client:

# Shell D:
. <ros2-install-dir>/setup.bash
ros2 run demo_nodes_cpp add_two_ints_client

CHANGELOG

Changelog for package ros1_bridge

0.8.2 (2020-01-17)

  • fix building test when ROS 1 diagnostic_msgs is isolated from roscpp (#236)
  • fix service with custom mapped message field (#234)
  • Contributors: Dirk Thomas

0.8.1 (2019-10-23)

  • fix showing duplicate keys in --print-pairs (#225)
  • fix bridging builtin_interfaces Duration and Time (#224)
  • Don\'t use features that will be deprecated (#222)
  • Contributors: Dirk Thomas, Peter Baughman

0.8.0 (2019-09-27)

  • Promote special CLI rules to flags. (#217)
  • Update __log_rosout_disable workaround to use --ros-args. (#216)
  • Clearer instructions for example (#211)
  • add services bridging to parameter_bridge (#176)
  • Contributors: Jose Luis Blanco-Claraco, Michel Hidalgo, cyrilleberger

0.7.3 (2019-08-02)

  • fix typename in static bridge (#209)
  • fix cosmetic in message (#207)
  • Use %zu print format for size_t (#204)
  • Fix parameter bridge for topic if ros1 and ros2 type have a different name (#177)
  • Contributors: Dirk Thomas, Emerson Knapp, cyrilleberger

0.7.2 (2019-05-29)

  • add note about rostopic echo (#202)
  • add workspace setup documentation (#201)
  • Contributors: Mabel Zhang

0.7.1 (2019-05-20)

  • Disable rosout logging for the bridge (#197)
  • Handle launch_testing assertExitCodes correctly (#193)
  • Support field selection (#174)
  • Use interface kind names properly in ROS2 interface type names. (#194)
  • Contributors: Juan Rodriguez Hortala, Michel Hidalgo, ivanpauno

0.7.0 (2019-05-08)

  • Adds interface type to ROS2 message type name. (#191)
  • fix build by passing options (#192)
  • changes to avoid deprecated API\'s (#189)
  • Corrected publish calls with shared_ptr signature, leftovers (#190)
  • Corrected publish calls with shared_ptr signature (#188)
  • Migrate launch tests to new launch_testing features & API (#179)
  • Some small fixes to the README (#186)
  • Fix the generator. (#185)
  • Merge pull request #183 from ros2/interface_specific_compilation_units
  • remove note about memory usage from README
  • split into interface specific compilation units
  • duplicate template before modifying it to track history
  • fix log messages (#182)
  • use safe_load instead of deprecated load (#180)
  • Merge pull request #178 from ros2/gonzalodepedro/fix-propagate-args-to-rcl-init
  • Allows propagations of cmd args to rclcpp::init
  • add section about DCO to CONTRIBUTING.md
  • Add launch along with launch_testing as test dependencies. (#171)
  • Switch to rclcpp logging and improve messages (#167)
  • invalidate wrong cached result for diagnostic_msgs (#170)
  • Drops legacy launch API usage. (#163)
  • export find_ros1_package cmake (#164)
  • ensure that the diagnostic_msgs package is from ROS 2 (#169)
  • Allow latching for ROS1 pub, and custom qos for ROS2 components (#162)
  • Allow external use of ros1_bridge library factories (#160)
  • Contributors: Chris Lalancette, Dirk Thomas, Gonzalo de Pedro, Gonzo, Karsten Knese, Michel Hidalgo, Mikael Arguedas, Paul Bovbel, William Woodall, ivanpauno

0.6.1 (2018-12-12)

  • exclude ros1 nodelets (#152)
  • fix is_package_mapping check (#151)
  • Contributors: Dirk Thomas, Karsten Knese

0.6.0 (2018-12-08)

  • expose convert function (#146)
  • support for custom field mapping for services (#147)
  • handle idl files correctly (#145)
  • Fix for actions subfolder introduction in ros2 message bridge (#143)
  • use new error handling API from rcutils (#141)
  • changed cmake message logger level (#138)
  • Contributors: Alberto Soragna, Dirk Thomas, Karsten Knese, Samuel Servulo, William Woodall

0.5.1 (2018-08-20)

  • Merge pull request #136 from ros2/update_docs_135
  • update doc to reflect that any mapping combination is supported
  • rule can be a message mapping even if a field mapping is provided as well (#135)
  • Contributors: Mikael Arguedas

0.5.0 (2018-06-27)

  • remove --build-tests which is an ament argument from colcon invocation
  • print service pairs as well (#124)
  • print message for all ROS 2 message pkgs (#123)
  • update README to use colcon and ROS Melodic (#122)
  • include module name which wasn\'t found in error message (#121)
  • use catkin_pkg to parse packages (#119)
  • migrate launch -> launch.legacy (#117)
  • Duplicate messages in bidirectional_bridge fix (#113)
  • Fix linter failures from includes (#110)
  • Map duration and time messages (#106)
  • clarify that all field must be listed explicitly (#109)
  • add an error message if the mapping rules are not a list (#107)
  • advise to ask questions on ROS answers
  • Contributors: ArkadiuszNiemiec, Dirk Thomas, Mikael Arguedas, Tully Foote, William Woodall, dhood

0.4.0 (2017-12-08)

  • match topic name printed in console (#102)
  • Update for rclcpp namespace removals (#101)
  • cmake 3.10 compatibility: pass absolute path to file(GENERATE) function (#100)
  • depend on rosidl_interfaces_packages group (#99)
  • Fix building of ros1_bridge against newer roscpp. (#98)
  • Merge pull request #97 from ros2/ament_cmake_pytest
  • use ament_cmake_pytest instead of ament_cmake_nose
  • Merge pull request #96 from ros2/print_type_names
  • print bridged type names
  • Increase timeout waiting for server for ros2 client in tests (#94)
  • update style to match latest uncrustify (#93)
  • Contributors: Brian Gerkey, Chris Lalancette, Dirk Thomas, Esteve Fernandez, Hunter Allen, Jackie Kay, Karsten Knese, Mikael Arguedas, Morgan Quigley, Rafal Kozik, Rafa

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ros1_bridge at answers.ros.org

ros1_bridge package from ros1_bridge repo

ros1_bridge

Package Summary

Tags No category tags.
Version 0.7.5
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/ros1_bridge.git
VCS Type git
VCS Version dashing
Last Updated 2020-03-13
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

A simple bridge between ROS 1 and ROS 2

Additional Links

No additional links.

Maintainers

  • Dirk Thomas

Authors

No additional authors.

Bridge communication between ROS 1 and ROS 2

This package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.

The bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed. Because of this its support is limited to only the message/service types available at compile time of the bridge. The bridge provided with the prebuilt ROS 2 binaries includes support for common ROS interfaces (messages/services), such as the interface packages listed in the ros2/common_interfaces repository and tf2_msgs. See the documentation for more details on how ROS 1 and ROS 2 interfaces are associated with each other. If you would like to use a bridge with other interfaces (including your own custom types), you will have to build the bridge from source (instructions below), after building and sourcing your custom types in separate ROS 1 and ROS 2 workspaces. See the documentation for an example setup.

For efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge. Note that before rostopic echo would work with bridged topics, a subscriber must already exist, in order for echo to determine the message type and then to create its own subscriber. You can use the --bridge-all-2to1-topics option to bridge all ROS 2 topics to ROS 1 so that tools such as rostopic list and rqt will see the topics even if there are no matching ROS 1 subscribers. Run ros2 run ros1_bridge dynamic_bridge -- --help for more options.

Prerequisites

In order to run the bridge you need to either:

  • get prebuilt binaries or
  • build the bridge as well as the other ROS 2 packages from source.

After that you can run both examples described below.

For all examples you need to source the environment of the install space where the bridge was built or unpacked to. Additionally you will need to either source the ROS 1 environment or at least set the ROS_MASTER_URI and run a roscore.

The following ROS 1 packages are required to build and use the bridge: * catkin * roscpp * roslaunch (for roscore executable) * rosmsg * std_msgs * as well as the Python package rospkg

To run the following examples you will also need these ROS 1 packages: * rosbash (for rosrun executable) * roscpp_tutorials * rospy_tutorials * rostopic * rqt_image_view

Building the bridge from source

Before continuing you should have the prerequisites for building ROS 2 from source installed following these instructions.

In the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case. If you run into trouble first make sure you have at least version 1.11.16 of ros_comm and rosbag.

The bridge uses pkg-config to find ROS 1 packages. ROS 2 packages are found through CMake using find_package(). Therefore the CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages.

Here are the steps for Linux and OSX.

You should first build everything but the ROS 1 bridge with normal colcon arguments. We don't recommend having your ROS 1 environment sourced during this step as it can add other libraries to the path.

colcon build --symlink-install --packages-skip ros1_bridge

Next you need to source the ROS 1 environment, for Linux and ROS Melodic that would be:

source /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash

The bridge will be built with support for any message/service packages that are on your path and have an associated mapping between ROS 1 and ROS 2. Therefore you must add any ROS 1 or ROS 2 workspaces that have message/service packages that you want to be bridged to your path before building the bridge. This can be done by adding explicit dependencies on the message/service packages to the package.xml of the bridge, so that colcon will add them to the path before it builds the bridge. Alternatively you can do it manually by sourcing the relevant workspaces yourself, e.g.:

# You have already sourced your ROS installation.
# Source your ROS 2 installation:
. <install-space-with-ros2>/local_setup.bash
# And if you have a ROS 1 overlay workspace, something like:
# . <install-space-to-ros1-overlay-ws>/setup.bash
# And if you have a ROS 2 overlay workspace, something like:
# . <install-space-to-ros2-overlay-ws>/local_setup.bash

Then build just the ROS 1 bridge:

colcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure

Note: If you are building on a memory constrained system you might want to limit the number of parallel jobs by setting e.g. the environment variable MAKEFLAGS=-j1.

Example 1: run the bridge and the example talker and listener

The talker and listener can be either a ROS 1 or a ROS 2 node. The bridge will pass the message along transparently.

Note: When you are running these demos make sure to only source the indicated workspaces. You will get errors from most tools if they have both workspaces in their environment.

Example 1a: ROS 1 talker and ROS 2 listener

First we start a ROS 1 roscore:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


Then we start the dynamic bridge which will watch the available ROS 1 and ROS 2 topics. Once a matching topic has been detected it starts to bridge the messages on this topic.

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

The program will start outputting the currently available topics in ROS 1 and ROS 2 in a regular interval.


Now we start the ROS 1 talker.

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun rospy_tutorials talker

The ROS 1 node will start printing the published messages to the console.


Now we start the ROS 2 listener from the demo_nodes_cpp ROS 2 package.

# Shell D:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_cpp listener

The ROS 2 node will start printing the received messages to the console.

When looking at the output in shell B there will be a line stating that the bridge for this topic has been created:

created 1to2 bridge for topic '/chatter' with ROS 1 type 'std_msgs/String' and ROS 2 type 'std_msgs/String'

At the end stop all programs with Ctrl-C. Once you stop either the talker or the listener in shell B a line will be stating that the bridge has been torn down:

removed 1to2 bridge for topic '/chatter'

Note: When the bridge is run using the default ROS 2 middleware implementation, which uses Fast RTPS, it does not always remove bridges instantly. See https://github.com/ros2/ros1_bridge/issues/38.

The screenshot shows all the shell windows and their expected content:

ROS 1 talker and ROS 2 listener

Example 1b: ROS 2 talker and ROS 1 listener

The steps are very similar to the previous example and therefore only the commands are described.

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 2 talker from the demo_nodes_py ROS 2 package.

# Shell C:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_py talker


Now we start the ROS 1 listener.

# Shell D:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun roscpp_tutorials listener

Example 2: run the bridge and exchange images

The second example will demonstrate the bridge passing along bigger and more complicated messages. A ROS 2 node is publishing images retrieved from a camera and on the ROS 1 side we use rqt_image_view to render the images in a GUI. And a ROS 1 publisher can send a message to toggle an option in the ROS 2 node.

First we start a ROS 1 roscore and the bridge:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <workspace-with-bridge>/install/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 1 GUI:

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rqt_image_view /image

--

Now we start the ROS 2 image publisher from the image_tools ROS 2 package:

# Shell D:
. <workspace-with-ros2>/install/setup.bash
ros2 run image_tools cam2image

You should see the current images in rqt_image_view which are coming from the ROS 2 node cam2image and are being passed along by the bridge.

--

To exercise the bridge in the opposite direction at the same time you can publish a message to the ROS 2 node from ROS 1. By publishing either true or false to the flip_image topic, the camera node will conditionally flip the image before sending it. You can either use the Message Publisher plugin in rqt to publish a std_msgs/Bool message on the topic flip_image, or run one of the two following rostopic commands:

# Shell E:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: true}"
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: false}"

The screenshot shows all the shell windows and their expected content (it was taken when Indigo was supported - you should use Melodic):

ROS 2 camera and ROS 1 rqt

Example 3: run the bridge for AddTwoInts service

In this example we will bridge a service TwoInts from ros/roscpp_tutorials and AddTwoInts from ros2/roscpp_examples.

While building, ros1_bridge looks for all installed ROS and ROS2 services. Found services are matched by comparing package name, service name and fields in a request and a response. If all names are the same in ROS and ROS2 service, the bridge will be created. It is also possible to pair services manually by creating a yaml file that will include names of corresponding services. You can find more information here.

So to make this example work, please make sure that the roscpp_tutorials package is installed on your system and the environment is set up correctly while you build ros1_bridge.

Launch ROS master

# Shell A:
. <ros-install-dir>/setup.bash
roscore -p 11311

Launch dynamic_bridge:

# Shell B:
. <ros-install-dir>/setup.bash
. <ros2-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

Launch TwoInts server:

# Shell C:
. <ros-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
rosrun roscpp_tutorials add_two_ints_server

Launch AddTwoInts client:

# Shell D:
. <ros2-install-dir>/setup.bash
ros2 run demo_nodes_cpp add_two_ints_client

CHANGELOG
No CHANGELOG found.

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ros1_bridge at answers.ros.org

ros1_bridge package from ros1_bridge repo

ros1_bridge

Package Summary

Tags No category tags.
Version 0.4.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/ros1_bridge.git
VCS Type git
VCS Version ardent
Last Updated 2017-12-09
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

A simple bridge between ROS 1 and ROS 2

Additional Links

No additional links.

Maintainers

  • Dirk Thomas

Authors

No additional authors.

Bridge communication between ROS 1 and ROS 2

This package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.

The bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed. Because of this its support is limited to only the message/service types available at compile time of the bridge. The bridge provided with the prebuilt ROS 2 binaries includes support for common ROS interfaces (messages/services), such as the interface packages listed in the ros2/common_interfaces repository and tf2_msgs. See the documentation for more details on how ROS 1 and ROS 2 interfaces are associated with each other. If you would like to use a bridge with other interfaces (including your own custom types), you will have to build the bridge from source (instructions below).

Note: For binary releases up to and including release-alpha8, some of the interfaces in common_interfaces are skipped - check the git tag of the release in question to see which interfaces were built.

For efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge. You can use the --bridge-all-2to1-topics option to bridge all ROS 2 topics to ROS 1 so that tools such as rostopic list and rqt will see the topics even if there are no matching ROS 1 subscribers. Run ros2 run ros1_bridge dynamic_bridge -- --help for more options.

Prerequisites

In order to run the bridge you need to either:

  • get prebuilt binaries or
  • build the bridge as well as the other ROS 2 packages from source.

After that you can run both examples described below.

For all examples you need to source the environment of the ament install space where the bridge was built or unpacked to. Additionally you will need to either source the ROS 1 environment or at least set the ROS_MASTER_URI and run a roscore.

The following ROS 1 packages are required to build and use the bridge: * catkin * roscpp * roslaunch (for roscore executable) * rosmsg * std_msgs * as well as the Python package rospkg

To run the following examples you will also need these ROS 1 packages: * rosbash (for rosrun executable) * roscpp_tutorials * rospy_tutorials * rostopic * rqt_image_view

Building the bridge from source

Before continuing you should have the prerequisites for building ROS 2 from source installed following these instructions.

In the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case. If you run into trouble first make sure you have at least version 1.11.16 of ros_comm and rosbag.

Also, building the ROS 1 bridge can consume a tremendous amount of memory (almost 4 GB of free RAM per thread while compiling) to the point that it can easily overwhelm a computer if done with parallel compilation enabled. As such, we recommend first building everything else as usual, then coming back to build the ROS 1 bridge without parallel compilation.

The bridge uses pkg-config to find ROS 1 packages. ROS 2 packages are found through CMake using find_package(). Therefore the CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages.

Here are the steps (for Linux and OSX; you probably don't have ROS 1 installed on Windows).

You should first build everything but the ROS 1 bridge with normal make arguments. We don't recommend having your ROS 1 environment sourced during this step as it can add OpenCV 3 to your path. The ROS 2 image demos you build in this step would then use OpenCV 3 and require it to be on your path when you run them, while the standard installation on Ubuntu Xenial is OpenCV 2.

src/ament/ament_tools/scripts/ament.py build --build-tests --symlink-install --skip-packages ros1_bridge

Next you need to source the ROS 1 environment, for Linux and ROS Kinetic that would be:

source /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash

The bridge will be built with support for any message/service packages that are on your path and have an associated mapping between ROS 1 and ROS 2. Therefore you must add any ROS 1 or ROS 2 workspaces that have message/service packages that you want to be bridged to your path before building the bridge. This can be done by adding explicit dependencies on the message/service packages to the package.xml of the bridge, so that ament will add them to the path before it builds the bridge. Alternatively you can do it manually by sourcing the relevant workspaces yourself, e.g.:

# You have already sourced your ROS installation.
# Source your ROS 2 installation:
. <install-space-with-ros2>/local_setup.bash
# And if you have a ROS 1 overlay workspace, something like:
# . <install-space-to-ros1-overlay-ws>/setup.bash
# And if you have a ROS 2 overlay workspace, something like:
# . <install-space-to-ros2-overlay-ws>/local_setup.bash

Then build just the ROS 1 bridge:

src/ament/ament_tools/scripts/ament.py build --build-tests --symlink-install --only ros1_bridge --force-cmake-configure

Note: If you are building on a memory constrained system you might want to limit the number of parallel jobs by passing e.g. -j1.

Example 1: run the bridge and the example talker and listener

The talker and listener can be either a ROS 1 or a ROS 2 node. The bridge will pass the message along transparently.

Note: When you are running these demos make sure to only source the indicated workspaces. You will get errors from most tools if they have both workspaces in their environment.

Example 1a: ROS 1 talker and ROS 2 listener

First we start a ROS 1 roscore:

# Shell A:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


Then we start the dynamic bridge which will watch the available ROS 1 and ROS 2 topics. Once a matching topic has been detected it starts to bridge the messages on this topic.

# Shell B:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

The program will start outputting the currently available topics in ROS 1 and ROS 2 in a regular interval.


Now we start the ROS 1 talker.

# Shell C:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun rospy_tutorials talker

The ROS 1 node will start printing the published messages to the console.


Now we start the ROS 2 listener from the demo_nodes_cpp ROS 2 package.

# Shell D:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_cpp listener

The ROS 2 node will start printing the received messages to the console.

When looking at the output in shell B there will be a line stating that the bridge for this topic has been created:

created 1to2 bridge for topic '/chatter' with ROS 1 type 'std_msgs/String' and ROS 2 type 'std_msgs/String'

At the end stop all programs with Ctrl-C. Once you stop either the talker or the listener in shell B a line will be stating that the bridge has been torn down:

removed 1to2 bridge for topic '/chatter'

Note: When the bridge is run using the default ROS 2 middleware implementation, which uses Fast RTPS, it does not always remove bridges instantly. See https://github.com/ros2/ros1_bridge/issues/38.

The screenshot shows all the shell windows and their expected content:

ROS 1 talker and ROS 2 listener

Example 1b: ROS 2 talker and ROS 1 listener

The steps are very similar to the previous example and therefore only the commands are described.

# Shell A:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


# Shell B:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 2 talker from the demo_nodes_py ROS 2 package.

# Shell C:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_py talker


Now we start the ROS 1 listener.

# Shell D:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun roscpp_tutorials listener

Example 2: run the bridge and exchange images

The second example will demonstrate the bridge passing along bigger and more complicated messages. A ROS 2 node is publishing images retrieved from a camera and on the ROS 1 side we use rqt_image_view to render the images in a GUI. And a ROS 1 publisher can send a message to toggle an option in the ROS 2 node.

First we start a ROS 1 roscore and the bridge:

# Shell A:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore

# Shell B:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <workspace-with-bridge>/install/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 1 GUI:

# Shell C:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rqt_image_view /image

--

Now we start the ROS 2 image publisher from the image_tools ROS 2 package:

# Shell D:
. <workspace-with-ros2>/install/setup.bash
ros2 run image_tools cam2image

You should see the current images in rqt_image_view which are coming from the ROS 2 node cam2image and are being passed along by the bridge.

--

To exercise the bridge in the opposite direction at the same time you can publish a message to the ROS 2 node from ROS 1. By publishing either true or false to the flip_image topic, the camera node will conditionally flip the image before sending it. You can either use the Message Publisher plugin in rqt to publish a std_msgs/Bool message on the topic flip_image, or run one of the two following rostopic commands:

# Shell E:
. /opt/ros/kinetic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: true}"
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: false}"

The screenshot shows all the shell windows and their expected content (it was taken when Indigo was supported - you should use Kinetic):

ROS 2 camera and ROS 1 rqt

Example 3: run the bridge for AddTwoInts service

In this example we will bridge a service TwoInts from ros/roscpp_tutorials and AddTwoInts from ros2/roscpp_examples.

While building, ros1_bridge looks for all installed ROS and ROS2 services. Found services are matched by comparing package name, service name and fields in a request and a response. If all names are the same in ROS and ROS2 service, the bridge will be created. It is also possible to pair services manually by creating a yaml file that will include names of corresponding services. You can find more information here.

So to make this example work, please make sure that the roscpp_tutorials package is installed on your system and the environment is set up correctly while you build ros1_bridge.

Launch ROS master

# Shell A:
. <ros-install-dir>/setup.bash
roscore -p 11311

Launch dynamic_bridge:

# Shell B:
. <ros-install-dir>/setup.bash
. <ros2-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

Launch TwoInts server:

# Shell C:
. <ros-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
rosrun roscpp_tutorials add_two_ints_server

Launch AddTwoInts client:

# Shell D:
. <ros2-install-dir>/setup.bash
ros2 run demo_nodes_cpp add_two_ints_client

CHANGELOG
No CHANGELOG found.

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ros1_bridge at answers.ros.org

ros1_bridge package from ros1_bridge repo

ros1_bridge

Package Summary

Tags No category tags.
Version 0.5.1
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/ros1_bridge.git
VCS Type git
VCS Version bouncy
Last Updated 2018-08-22
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

A simple bridge between ROS 1 and ROS 2

Additional Links

No additional links.

Maintainers

  • Dirk Thomas

Authors

No additional authors.

Bridge communication between ROS 1 and ROS 2

This package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.

The bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed. Because of this its support is limited to only the message/service types available at compile time of the bridge. The bridge provided with the prebuilt ROS 2 binaries includes support for common ROS interfaces (messages/services), such as the interface packages listed in the ros2/common_interfaces repository and tf2_msgs. See the documentation for more details on how ROS 1 and ROS 2 interfaces are associated with each other. If you would like to use a bridge with other interfaces (including your own custom types), you will have to build the bridge from source (instructions below).

Note: For binary releases up to and including release-alpha8, some of the interfaces in common_interfaces are skipped - check the git tag of the release in question to see which interfaces were built.

For efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge. You can use the --bridge-all-2to1-topics option to bridge all ROS 2 topics to ROS 1 so that tools such as rostopic list and rqt will see the topics even if there are no matching ROS 1 subscribers. Run ros2 run ros1_bridge dynamic_bridge -- --help for more options.

Prerequisites

In order to run the bridge you need to either:

  • get prebuilt binaries or
  • build the bridge as well as the other ROS 2 packages from source.

After that you can run both examples described below.

For all examples you need to source the environment of the install space where the bridge was built or unpacked to. Additionally you will need to either source the ROS 1 environment or at least set the ROS_MASTER_URI and run a roscore.

The following ROS 1 packages are required to build and use the bridge: * catkin * roscpp * roslaunch (for roscore executable) * rosmsg * std_msgs * as well as the Python package rospkg

To run the following examples you will also need these ROS 1 packages: * rosbash (for rosrun executable) * roscpp_tutorials * rospy_tutorials * rostopic * rqt_image_view

Building the bridge from source

Before continuing you should have the prerequisites for building ROS 2 from source installed following these instructions.

In the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case. If you run into trouble first make sure you have at least version 1.11.16 of ros_comm and rosbag.

Also, building the ROS 1 bridge can consume a tremendous amount of memory (almost 4 GB of free RAM per thread while compiling) to the point that it can easily overwhelm a computer if done with parallel compilation enabled. As such, we recommend first building everything else as usual, then coming back to build the ROS 1 bridge without parallel compilation.

The bridge uses pkg-config to find ROS 1 packages. ROS 2 packages are found through CMake using find_package(). Therefore the CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages.

Here are the steps (for Linux and OSX; you probably don't have ROS 1 installed on Windows).

You should first build everything but the ROS 1 bridge with normal make arguments. We don't recommend having your ROS 1 environment sourced during this step as it can add OpenCV 3 to your path. The ROS 2 image demos you build in this step would then use OpenCV 3 and require it to be on your path when you run them, while the standard installation on Ubuntu Xenial is OpenCV 2.

colcon build --symlink-install --packages-skip ros1_bridge

Next you need to source the ROS 1 environment, for Linux and ROS Melodic that would be:

source /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash

The bridge will be built with support for any message/service packages that are on your path and have an associated mapping between ROS 1 and ROS 2. Therefore you must add any ROS 1 or ROS 2 workspaces that have message/service packages that you want to be bridged to your path before building the bridge. This can be done by adding explicit dependencies on the message/service packages to the package.xml of the bridge, so that colcon will add them to the path before it builds the bridge. Alternatively you can do it manually by sourcing the relevant workspaces yourself, e.g.:

# You have already sourced your ROS installation.
# Source your ROS 2 installation:
. <install-space-with-ros2>/local_setup.bash
# And if you have a ROS 1 overlay workspace, something like:
# . <install-space-to-ros1-overlay-ws>/setup.bash
# And if you have a ROS 2 overlay workspace, something like:
# . <install-space-to-ros2-overlay-ws>/local_setup.bash

Then build just the ROS 1 bridge:

colcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure

Note: If you are building on a memory constrained system you might want to limit the number of parallel jobs by setting e.g. the environment variable MAKEFLAGS=-j1.

Example 1: run the bridge and the example talker and listener

The talker and listener can be either a ROS 1 or a ROS 2 node. The bridge will pass the message along transparently.

Note: When you are running these demos make sure to only source the indicated workspaces. You will get errors from most tools if they have both workspaces in their environment.

Example 1a: ROS 1 talker and ROS 2 listener

First we start a ROS 1 roscore:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


Then we start the dynamic bridge which will watch the available ROS 1 and ROS 2 topics. Once a matching topic has been detected it starts to bridge the messages on this topic.

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

The program will start outputting the currently available topics in ROS 1 and ROS 2 in a regular interval.


Now we start the ROS 1 talker.

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun rospy_tutorials talker

The ROS 1 node will start printing the published messages to the console.


Now we start the ROS 2 listener from the demo_nodes_cpp ROS 2 package.

# Shell D:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_cpp listener

The ROS 2 node will start printing the received messages to the console.

When looking at the output in shell B there will be a line stating that the bridge for this topic has been created:

created 1to2 bridge for topic '/chatter' with ROS 1 type 'std_msgs/String' and ROS 2 type 'std_msgs/String'

At the end stop all programs with Ctrl-C. Once you stop either the talker or the listener in shell B a line will be stating that the bridge has been torn down:

removed 1to2 bridge for topic '/chatter'

Note: When the bridge is run using the default ROS 2 middleware implementation, which uses Fast RTPS, it does not always remove bridges instantly. See https://github.com/ros2/ros1_bridge/issues/38.

The screenshot shows all the shell windows and their expected content:

ROS 1 talker and ROS 2 listener

Example 1b: ROS 2 talker and ROS 1 listener

The steps are very similar to the previous example and therefore only the commands are described.

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 2 talker from the demo_nodes_py ROS 2 package.

# Shell C:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_py talker


Now we start the ROS 1 listener.

# Shell D:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun roscpp_tutorials listener

Example 2: run the bridge and exchange images

The second example will demonstrate the bridge passing along bigger and more complicated messages. A ROS 2 node is publishing images retrieved from a camera and on the ROS 1 side we use rqt_image_view to render the images in a GUI. And a ROS 1 publisher can send a message to toggle an option in the ROS 2 node.

First we start a ROS 1 roscore and the bridge:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <workspace-with-bridge>/install/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 1 GUI:

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rqt_image_view /image

--

Now we start the ROS 2 image publisher from the image_tools ROS 2 package:

# Shell D:
. <workspace-with-ros2>/install/setup.bash
ros2 run image_tools cam2image

You should see the current images in rqt_image_view which are coming from the ROS 2 node cam2image and are being passed along by the bridge.

--

To exercise the bridge in the opposite direction at the same time you can publish a message to the ROS 2 node from ROS 1. By publishing either true or false to the flip_image topic, the camera node will conditionally flip the image before sending it. You can either use the Message Publisher plugin in rqt to publish a std_msgs/Bool message on the topic flip_image, or run one of the two following rostopic commands:

# Shell E:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: true}"
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: false}"

The screenshot shows all the shell windows and their expected content (it was taken when Indigo was supported - you should use Melodic):

ROS 2 camera and ROS 1 rqt

Example 3: run the bridge for AddTwoInts service

In this example we will bridge a service TwoInts from ros/roscpp_tutorials and AddTwoInts from ros2/roscpp_examples.

While building, ros1_bridge looks for all installed ROS and ROS2 services. Found services are matched by comparing package name, service name and fields in a request and a response. If all names are the same in ROS and ROS2 service, the bridge will be created. It is also possible to pair services manually by creating a yaml file that will include names of corresponding services. You can find more information here.

So to make this example work, please make sure that the roscpp_tutorials package is installed on your system and the environment is set up correctly while you build ros1_bridge.

Launch ROS master

# Shell A:
. <ros-install-dir>/setup.bash
roscore -p 11311

Launch dynamic_bridge:

# Shell B:
. <ros-install-dir>/setup.bash
. <ros2-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

Launch TwoInts server:

# Shell C:
. <ros-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
rosrun roscpp_tutorials add_two_ints_server

Launch AddTwoInts client:

# Shell D:
. <ros2-install-dir>/setup.bash
ros2 run demo_nodes_cpp add_two_ints_client

CHANGELOG
No CHANGELOG found.

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ros1_bridge at answers.ros.org

ros1_bridge package from ros1_bridge repo

ros1_bridge

Package Summary

Tags No category tags.
Version 0.6.2
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros2/ros1_bridge.git
VCS Type git
VCS Version crystal
Last Updated 2019-05-20
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

A simple bridge between ROS 1 and ROS 2

Additional Links

No additional links.

Maintainers

  • Dirk Thomas

Authors

No additional authors.

Bridge communication between ROS 1 and ROS 2

This package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.

The bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed. Because of this its support is limited to only the message/service types available at compile time of the bridge. The bridge provided with the prebuilt ROS 2 binaries includes support for common ROS interfaces (messages/services), such as the interface packages listed in the ros2/common_interfaces repository and tf2_msgs. See the documentation for more details on how ROS 1 and ROS 2 interfaces are associated with each other. If you would like to use a bridge with other interfaces (including your own custom types), you will have to build the bridge from source (instructions below).

Note: For binary releases up to and including release-alpha8, some of the interfaces in common_interfaces are skipped - check the git tag of the release in question to see which interfaces were built.

For efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge. You can use the --bridge-all-2to1-topics option to bridge all ROS 2 topics to ROS 1 so that tools such as rostopic list and rqt will see the topics even if there are no matching ROS 1 subscribers. Run ros2 run ros1_bridge dynamic_bridge -- --help for more options.

Prerequisites

In order to run the bridge you need to either:

  • get prebuilt binaries or
  • build the bridge as well as the other ROS 2 packages from source.

After that you can run both examples described below.

For all examples you need to source the environment of the install space where the bridge was built or unpacked to. Additionally you will need to either source the ROS 1 environment or at least set the ROS_MASTER_URI and run a roscore.

The following ROS 1 packages are required to build and use the bridge: * catkin * roscpp * roslaunch (for roscore executable) * rosmsg * std_msgs * as well as the Python package rospkg

To run the following examples you will also need these ROS 1 packages: * rosbash (for rosrun executable) * roscpp_tutorials * rospy_tutorials * rostopic * rqt_image_view

Building the bridge from source

Before continuing you should have the prerequisites for building ROS 2 from source installed following these instructions.

In the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case. If you run into trouble first make sure you have at least version 1.11.16 of ros_comm and rosbag.

Also, building the ROS 1 bridge can consume a tremendous amount of memory (almost 4 GB of free RAM per thread while compiling) to the point that it can easily overwhelm a computer if done with parallel compilation enabled. As such, we recommend first building everything else as usual, then coming back to build the ROS 1 bridge without parallel compilation.

The bridge uses pkg-config to find ROS 1 packages. ROS 2 packages are found through CMake using find_package(). Therefore the CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages.

Here are the steps (for Linux and OSX; you probably don't have ROS 1 installed on Windows).

You should first build everything but the ROS 1 bridge with normal make arguments. We don't recommend having your ROS 1 environment sourced during this step as it can add OpenCV 3 to your path. The ROS 2 image demos you build in this step would then use OpenCV 3 and require it to be on your path when you run them, while the standard installation on Ubuntu Xenial is OpenCV 2.

colcon build --symlink-install --packages-skip ros1_bridge

Next you need to source the ROS 1 environment, for Linux and ROS Melodic that would be:

source /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash

The bridge will be built with support for any message/service packages that are on your path and have an associated mapping between ROS 1 and ROS 2. Therefore you must add any ROS 1 or ROS 2 workspaces that have message/service packages that you want to be bridged to your path before building the bridge. This can be done by adding explicit dependencies on the message/service packages to the package.xml of the bridge, so that colcon will add them to the path before it builds the bridge. Alternatively you can do it manually by sourcing the relevant workspaces yourself, e.g.:

# You have already sourced your ROS installation.
# Source your ROS 2 installation:
. <install-space-with-ros2>/local_setup.bash
# And if you have a ROS 1 overlay workspace, something like:
# . <install-space-to-ros1-overlay-ws>/setup.bash
# And if you have a ROS 2 overlay workspace, something like:
# . <install-space-to-ros2-overlay-ws>/local_setup.bash

Then build just the ROS 1 bridge:

colcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure

Note: If you are building on a memory constrained system you might want to limit the number of parallel jobs by setting e.g. the environment variable MAKEFLAGS=-j1.

Example 1: run the bridge and the example talker and listener

The talker and listener can be either a ROS 1 or a ROS 2 node. The bridge will pass the message along transparently.

Note: When you are running these demos make sure to only source the indicated workspaces. You will get errors from most tools if they have both workspaces in their environment.

Example 1a: ROS 1 talker and ROS 2 listener

First we start a ROS 1 roscore:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


Then we start the dynamic bridge which will watch the available ROS 1 and ROS 2 topics. Once a matching topic has been detected it starts to bridge the messages on this topic.

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

The program will start outputting the currently available topics in ROS 1 and ROS 2 in a regular interval.


Now we start the ROS 1 talker.

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun rospy_tutorials talker

The ROS 1 node will start printing the published messages to the console.


Now we start the ROS 2 listener from the demo_nodes_cpp ROS 2 package.

# Shell D:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_cpp listener

The ROS 2 node will start printing the received messages to the console.

When looking at the output in shell B there will be a line stating that the bridge for this topic has been created:

created 1to2 bridge for topic '/chatter' with ROS 1 type 'std_msgs/String' and ROS 2 type 'std_msgs/String'

At the end stop all programs with Ctrl-C. Once you stop either the talker or the listener in shell B a line will be stating that the bridge has been torn down:

removed 1to2 bridge for topic '/chatter'

Note: When the bridge is run using the default ROS 2 middleware implementation, which uses Fast RTPS, it does not always remove bridges instantly. See https://github.com/ros2/ros1_bridge/issues/38.

The screenshot shows all the shell windows and their expected content:

ROS 1 talker and ROS 2 listener

Example 1b: ROS 2 talker and ROS 1 listener

The steps are very similar to the previous example and therefore only the commands are described.

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore


# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <install-space-with-bridge>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 2 talker from the demo_nodes_py ROS 2 package.

# Shell C:
. <install-space-with-ros2>/setup.bash
ros2 run demo_nodes_py talker


Now we start the ROS 1 listener.

# Shell D:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rosrun roscpp_tutorials listener

Example 2: run the bridge and exchange images

The second example will demonstrate the bridge passing along bigger and more complicated messages. A ROS 2 node is publishing images retrieved from a camera and on the ROS 1 side we use rqt_image_view to render the images in a GUI. And a ROS 1 publisher can send a message to toggle an option in the ROS 2 node.

First we start a ROS 1 roscore and the bridge:

# Shell A:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
roscore

# Shell B:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
. <workspace-with-bridge>/install/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge


Now we start the ROS 1 GUI:

# Shell C:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rqt_image_view /image

--

Now we start the ROS 2 image publisher from the image_tools ROS 2 package:

# Shell D:
. <workspace-with-ros2>/install/setup.bash
ros2 run image_tools cam2image

You should see the current images in rqt_image_view which are coming from the ROS 2 node cam2image and are being passed along by the bridge.

--

To exercise the bridge in the opposite direction at the same time you can publish a message to the ROS 2 node from ROS 1. By publishing either true or false to the flip_image topic, the camera node will conditionally flip the image before sending it. You can either use the Message Publisher plugin in rqt to publish a std_msgs/Bool message on the topic flip_image, or run one of the two following rostopic commands:

# Shell E:
. /opt/ros/melodic/setup.bash
# Or, on OSX, something like:
# . ~/ros_catkin_ws/install_isolated/setup.bash
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: true}"
rostopic pub -r 1 /flip_image std_msgs/Bool "{data: false}"

The screenshot shows all the shell windows and their expected content (it was taken when Indigo was supported - you should use Melodic):

ROS 2 camera and ROS 1 rqt

Example 3: run the bridge for AddTwoInts service

In this example we will bridge a service TwoInts from ros/roscpp_tutorials and AddTwoInts from ros2/roscpp_examples.

While building, ros1_bridge looks for all installed ROS and ROS2 services. Found services are matched by comparing package name, service name and fields in a request and a response. If all names are the same in ROS and ROS2 service, the bridge will be created. It is also possible to pair services manually by creating a yaml file that will include names of corresponding services. You can find more information here.

So to make this example work, please make sure that the roscpp_tutorials package is installed on your system and the environment is set up correctly while you build ros1_bridge.

Launch ROS master

# Shell A:
. <ros-install-dir>/setup.bash
roscore -p 11311

Launch dynamic_bridge:

# Shell B:
. <ros-install-dir>/setup.bash
. <ros2-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

Launch TwoInts server:

# Shell C:
. <ros-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
rosrun roscpp_tutorials add_two_ints_server

Launch AddTwoInts client:

# Shell D:
. <ros2-install-dir>/setup.bash
ros2 run demo_nodes_cpp add_two_ints_client

CHANGELOG
No CHANGELOG found.

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged ros1_bridge at answers.ros.org