{"id":20099115,"url":"https://github.com/ros2/ros1_bridge","last_synced_at":"2025-05-15T02:07:27.380Z","repository":{"id":33899195,"uuid":"37613710","full_name":"ros2/ros1_bridge","owner":"ros2","description":"ROS 2 package that provides bidirectional communication between ROS 1 and ROS 2","archived":false,"fork":false,"pushed_at":"2025-05-06T14:27:58.000Z","size":1555,"stargazers_count":522,"open_issues_count":78,"forks_count":319,"subscribers_count":29,"default_branch":"master","last_synced_at":"2025-05-06T15:48:46.373Z","etag":null,"topics":["hacktoberfest"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ros2.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.rst","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2015-06-17T18:36:47.000Z","updated_at":"2025-05-06T14:28:02.000Z","dependencies_parsed_at":"2023-02-19T09:15:38.114Z","dependency_job_id":"7d410c6f-e7d5-4d1e-972a-60f5608d1c09","html_url":"https://github.com/ros2/ros1_bridge","commit_stats":{"total_commits":282,"total_committers":48,"mean_commits":5.875,"dds":0.6028368794326241,"last_synced_commit":"3d5328dc21564d2130b4ded30afe5cd1c41cf033"},"previous_names":[],"tags_count":44,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ros2%2Fros1_bridge","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ros2%2Fros1_bridge/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ros2%2Fros1_bridge/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ros2%2Fros1_bridge/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ros2","download_url":"https://codeload.github.com/ros2/ros1_bridge/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254259383,"owners_count":22040820,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["hacktoberfest"],"created_at":"2024-11-13T17:08:19.117Z","updated_at":"2025-05-15T02:07:27.373Z","avatar_url":"https://github.com/ros2.png","language":"C++","funding_links":[],"categories":["Network and Middleware","System"],"sub_categories":["Real-Time Kernel","Network and Middleware"],"readme":"# Bridge communication between ROS 1 and ROS 2\n\nThis package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.\n\nThe bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed.\nBecause of this its support is limited to only the message/service types available at compile time of the bridge.\nThe 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](https://github.com/ros2/common_interfaces) and `tf2_msgs`.\nSee [the documentation](doc/index.rst) for more details on how ROS 1 and ROS 2 interfaces are associated with each other.\nIf 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.\nSee [the documentation](doc/index.rst) for an example setup.\n\nFor efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge.\nAs a result using `ros2 topic echo \u003ctopic-name\u003e` doesn't work but fails with an error message `Could not determine the type for the passed topic` if no other subscribers are present since the dynamic bridge hasn't bridged the topic yet.\nAs a workaround the topic type can be specified explicitly `ros2 topic echo \u003ctopic-name\u003e \u003ctopic-type\u003e` which triggers the bridging of the topic since the `echo` command represents the necessary subscriber.\nOn the ROS 1 side `rostopic echo` doesn't have an option to specify the topic type explicitly.\nTherefore it can't be used with the dynamic bridge if no other subscribers are present.\nAs an alternative you can use the `--bridge-all-2to1-topics` option to bridge all ROS 2 topics to ROS 1 so that tools such as `rostopic echo`, `rostopic list` and `rqt` will see the topics even if there are no matching ROS 1 subscribers.\nRun `ros2 run ros1_bridge dynamic_bridge -- --help` for more options.\n\n## Supported ROS and Ubuntu Versions\n\n\u003e ⚠️ **Important Compatibility Notice**\n\n- `ros1_bridge` **requires ROS 1**, which has reached [end-of-life (EOL)](https://www.ros.org/reps/rep-0003.html#noetic-ninjemys-may-2020-may-2025) as of **May 2025** for ROS Noetic.\n- Ubuntu **24.04 LTS** does **not support ROS 1**, and therefore is **not compatible** with `ros1_bridge`.\n\n| Ubuntu Version | Supported ROS 1 Versions  | Supported ROS 2 Versions              | `ros1_bridge` Support            |\n|----------------|----------------|---------------------------------------|----------------------------------|\n| 20.04 (Focal)  | Noetic Ninjemys   | Foxy Fitzroy (EOL), Galactic Geochelone (EOL), Humble Hawksbill    | ✅ Full support                  |\n| 22.04 (Jammy)  | ⚠️ Partial (unsupported officially) | Humble Hawksbill, Iron Irwini | ⚠️ Requires building from source |\n| 24.04 (Noble)  | ❌ Not available | Jazzy Jalisco, Kilted Kaiju          | ❌ Not supported                 |\n\nTo use `ros1_bridge`, you must use a system where both ROS 1 and ROS 2 are installable and buildable. Mixing ROS distributions across unsupported Ubuntu versions is **not recommended** and may lead to broken builds or missing dependencies.\n\n## Prerequisites\n\nIn order to run the bridge you need to either:\n\n* get [prebuilt binaries](https://github.com/ros2/ros2/releases) or\n* build the bridge as well as the other ROS 2 packages from source.\n\nAfter that you can run both examples described below.\n\nFor all examples you need to source the environment of the install space where the bridge was built or unpacked to.\nAdditionally you will need to either source the ROS 1 environment or at least set the `ROS_MASTER_URI` and run a `roscore`.\n\nThe following ROS 1 packages are required to build and use the bridge:\n* `catkin`\n* `roscpp`\n* `roslaunch` (for `roscore` executable)\n* `rosmsg`\n* `std_msgs`\n* as well as the Python package `rospkg`\n\nTo run the following examples you will also need these ROS 1 packages:\n* `rosbash` (for `rosrun` executable)\n* `roscpp_tutorials`\n* `rospy_tutorials`\n* `rostopic`\n* `rqt_image_view`\n\n### Prerequisites for the examples in this file\n\nIn order to make the examples below portable between versions of ROS, we define two environment variables, `ROS1_INSTALL_PATH` and `ROS2_INSTALL_PATH`. \nThese are defined as the paths to the installation location of their respective ROS versions.\n\nIf you installed Noetic in the default location, then the definition of `ROS1_INSTALL_PATH` will be `/opt/ros/noetic`.\n\nBuilding the bridge as described below requires you to build all of ROS 2.\nWe assume that you have downloaded it to `~/ros2_rolling`, and that is where you plan on building it.\nIn this case, `ROS2_INSTALL_PATH` will be defined as `~/ros2_rolling/install`.\n\nIf you've chosen to install either or both versions of ROS somewhere else, you will need adjust the definitions below to match your installation paths.\n\nBecause these definitions are used continuously throughout this page, it is useful to add the following lines to your shell startup file (`~/.bashrc` if you are using `bash`, `~/.zshrc` if you are using `zsh`).\nModify these definitions as appropriate for the versions of ROS that you're using, and for the shell that you're using.\n\n\n```bash\nexport ROS1_INSTALL_PATH=/opt/ros/noetic\nexport ROS2_INSTALL_PATH=~/ros2_rolling/install\n```\n\nNote that no trailing '/' character is used in either definition.\nIf you have problems involving paths, please verify that you have the correct path to the installation location, and that you do not have a trailing '/' in either definition.\n\n### Building the bridge from source\n\nBefore continuing you should have the prerequisites for building ROS 2 from source installed following [these instructions](https://github.com/ros2/ros2/wiki/Installation).\n\nIn the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case.\nIf you run into trouble first make sure you have at least version `1.11.16` of `ros_comm` and `rosbag`.\n\nThe bridge uses `pkg-config` to find ROS 1 packages.\nROS 2 packages are found through CMake using `find_package()`.\nTherefore the `CMAKE_PREFIX_PATH` must not contain paths from ROS 1 which would overlay ROS 2 packages.\n\nHere are the steps for Linux and OSX.\n\nYou should first build everything but the ROS 1 bridge with normal colcon arguments.\nWe don't recommend having your ROS 1 environment sourced during this step as it can add other libraries to the path.\n\n\n```bash\ncolcon build --symlink-install --packages-skip ros1_bridge\n```\n\nNext you need to source the ROS 1 environment.\nIf you set the `ROS1_INSTALL_PATH` environment variable as described above, then the following will source the correct `setup.bash` file.\n\n\n```bash\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\n```\n\nThe 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.\nTherefore 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.\nThis 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.\nAlternatively you can do it manually by sourcing the relevant workspaces yourself, e.g.:\n\n\n```bash\n# You have already sourced your ROS installation.\n# Source your ROS 2 installation:\nsource ${ROS2_INSTALL_PATH}/setup.bash\n# And if you have a ROS 1 overlay workspace, something like:\n# . \u003cinstall-space-to-ros1-overlay-ws\u003e/setup.bash\n# And if you have a ROS 2 overlay workspace, something like:\n# . \u003cinstall-space-to-ros2-overlay-ws\u003e/local_setup.bash\n```\n\nThen build just the ROS 1 bridge:\n\n\n```bash\ncolcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure\n```\n\n*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`.\n\n\n## Example 1: run the bridge and the example talker and listener\n\nThe talker and listener can be either a ROS 1 or a ROS 2 node.\nThe bridge will pass the message along transparently.\n\n*Note:* When you are running these demos make sure to only source the indicated workspaces.\nYou will get errors from most tools if they have both workspaces in their environment.\n\n\n### Example 1a: ROS 1 talker and ROS 2 listener\n\nFirst we start a ROS 1 `roscore`:\n\n\n```bash\n# Shell A (ROS 1 only):\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nroscore\n```\n\n---\n\nThen we start the dynamic bridge which will watch the available ROS 1 and ROS 2 topics.\nOnce a *matching* topic has been detected it starts to bridge the messages on this topic.\n\n\n```bash\n# Shell B (ROS 1 + ROS 2):\n# Source ROS 1 first:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\n# Source ROS 2 next:\nsource ${ROS2_INSTALL_PATH}/setup.bash\n# For example:\n# . /opt/ros/dashing/setup.bash\nexport ROS_MASTER_URI=http://localhost:11311\nros2 run ros1_bridge dynamic_bridge\n```\n\nThe program will start outputting the currently available topics in ROS 1 and ROS 2 in a regular interval.\n\n---\n\nNow we start the ROS 1 talker.\n\n\n```bash\n# Shell C:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nrosrun rospy_tutorials talker\n```\n\nThe ROS 1 node will start printing the published messages to the console.\n\n---\n\nNow we start the ROS 2 listener from the `demo_nodes_cpp` ROS 2 package.\n\n\n```bash\n# Shell D:\nsource ${ROS2_INSTALL_PATH}/setup.bash\nros2 run demo_nodes_cpp listener\n```\n\nThe ROS 2 node will start printing the received messages to the console.\n\nWhen looking at the output in *shell B* there will be a line stating that the bridge for this topic has been created:\n\n\n```bash\ncreated 1to2 bridge for topic '/chatter' with ROS 1 type 'std_msgs/String' and ROS 2 type 'std_msgs/String'\n```\n\nAt the end stop all programs with `Ctrl-C`.\nOnce you stop either the talker or the listener in *shell B* a line will be stating that the bridge has been torn down:\n\n\n```bash\nremoved 1to2 bridge for topic '/chatter'\n```\n\nThe screenshot shows all the shell windows and their expected content:\n\n![ROS 1 talker and ROS 2 listener](doc/ros1_talker_ros2_listener.png)\n\n\n### Example 1b: ROS 2 talker and ROS 1 listener\n\nThe steps are very similar to the previous example and therefore only the commands are described.\n\n\n```bash\n# Shell A:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nroscore\n```\n\n---\n\n\n```bash\n# Shell B:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nsource ${ROS2_INSTALL_PATH}/setup.bash\nexport ROS_MASTER_URI=http://localhost:11311\nros2 run ros1_bridge dynamic_bridge\n```\n\n---\n\nNow we start the ROS 2 talker from the `demo_nodes_py` ROS 2 package.\n\n```bash\n# Shell C:\nsource ${ROS2_INSTALL_PATH}/setup.bash\nros2 run demo_nodes_py talker\n```\n\n---\n\nNow we start the ROS 1 listener.\n\n```bash\n# Shell D:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nrosrun roscpp_tutorials listener\n```\n\n## Example 2: run the bridge and exchange images\n\nThe second example will demonstrate the bridge passing along bigger and more complicated messages.\nA 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.\nAnd a ROS 1 publisher can send a message to toggle an option in the ROS 2 node.\n\nFirst we start a ROS 1 `roscore` and the bridge:\n\n```bash\n# Shell A:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nroscore\n```\n\n```bash\n# Shell B:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nsource ${ROS2_INSTALL_PATH}/install/setup.bash\nexport ROS_MASTER_URI=http://localhost:11311\nros2 run ros1_bridge dynamic_bridge\n```\n\n---\n\nNow we start the ROS 1 GUI:\n\n```bash\n# Shell C:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nrqt_image_view /image\n```\n\n---\n\nNow we start the ROS 2 image publisher from the `image_tools` ROS 2 package:\n```bash\n# Shell D:\nsource ${ROS2_INSTALL_PATH}/install/setup.bash\nros2 run image_tools cam2image\n```\n\nYou 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.\n\n---\n\nTo exercise the bridge in the opposite direction at the same time you can publish a message to the ROS 2 node from ROS 1.\nBy publishing either `true` or `false` to the `flip_image` topic, the camera node will conditionally flip the image before sending it.\nYou 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:\n\n\n```bash\n# Shell E:\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nrostopic pub -r 1 /flip_image std_msgs/Bool \"{data: true}\"\nrostopic pub -r 1 /flip_image std_msgs/Bool \"{data: false}\"\n```\n\nThe screenshot shows all the shell windows and their expected content (it was taken when Indigo was supported - you should use Melodic):\n\n![ROS 2 camera and ROS 1 rqt](doc/ros2_camera_ros1_rqt.png)\n\n## Example 3: run the bridge for AddTwoInts service\n\nIn this example we will bridge a service TwoInts from\n[ros/roscpp_tutorials](https://github.com/ros/ros_tutorials) and AddTwoInts from\n[ros2/roscpp_examples](https://github.com/ros2/examples).\n\nWhile building, ros1_bridge looks for all installed ROS and ROS2 services.\nFound services are matched by comparing package name, service name and fields in a request and a response.\nIf all names are the same in ROS and ROS2 service, the bridge will be created.\nIt is also possible to pair services manually by creating a yaml file that will include names of corresponding services.\nYou can find more information [here](doc/index.rst).\n\nSo to make this example work, please make sure that the roscpp_tutorials package\nis installed on your system and the environment is set up correctly while you build ros1_bridge.\n\nLaunch ROS master\n\n```bash\n# Shell A:\nsource ${ROS1_INSTALL_PATH}/setup.bash\nroscore -p 11311\n```\n\nLaunch dynamic_bridge:\n\n```bash\n# Shell B:\nsource ${ROS1_INSTALL_PATH}/setup.bash\nsource ${ROS2_INSTALL_PATH}/setup.bash\nexport ROS_MASTER_URI=http://localhost:11311\nros2 run ros1_bridge dynamic_bridge\n```\n\nLaunch TwoInts server:\n\n```bash\n# Shell C:\nsource ${ROS1_INSTALL_PATH}/setup.bash\nexport ROS_MASTER_URI=http://localhost:11311\nrosrun roscpp_tutorials add_two_ints_server\n```\n\nLaunch AddTwoInts client:\n\n```bash\n# Shell D:\nsource ${ROS2_INSTALL_PATH}/setup.bash\nros2 run demo_nodes_cpp add_two_ints_client\n```\n\n## Example 4: bridge only selected topics and services\nThis example expands on example 3 by selecting a subset of topics and services to be bridged.\nThis is handy when, for example, you have a system that runs most of it's stuff in either ROS 1 or ROS 2 but needs a few nodes from the 'opposite' version of ROS.\nWhere the `dynamic_bridge` bridges all topics and service, the `parameter_bridge` uses the ROS 1 parameter server to choose which topics and services are bridged.\n**Note**: The service bridge is **monodirectional**. You must use either `services_2_to_1` and/or `services_1_to_2` to bridge ROS 2 -\u003e ROS 1 or ROS 1 -\u003e ROS 2 services accordingly.\nFor example, to bridge only the `/chatter` topic bidirectionally, and the `/add_two_ints service` from ROS 2 to ROS 1 only, create this configuration file, `bridge.yaml`:\n\n```yaml\ntopics:\n  -\n    topic: /chatter  # Topic name on both ROS 1 and ROS 2\n    type: std_msgs/msg/String  # Type of topic to bridge\n    queue_size: 1  # Queue size\nservices_2_to_1:\n  -\n    service: /add_two_ints  # ROS 1 service name\n    type: roscpp_tutorials/TwoInts  # The ROS 1 service type name\n```\n\nStart a ROS 1 roscore:\n\n```bash\n# Shell A (ROS 1 only):\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nroscore\n```\n\nThen load the bridge.yaml config file and start the talker to publish on the `/chatter` topic:\n\n```bash\nShell B: (ROS 1 only):\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\nrosparam load bridge.yaml\n\nrosrun rospy_tutorials talker\n```\n\n```bash\nShell C: (ROS 1 only):\nsource ${ROS1_INSTALL_PATH}/setup.bash\n# Or, on OSX, something like:\n# . ~/ros_catkin_ws/install_isolated/setup.bash\n\nrosrun roscpp_tutorials add_two_ints_server\n```\n\nThen, in a few ROS 2 terminals:\n\n```bash\n# Shell D:\nsource ${ROS2_INSTALL_PATH}/setup.bash\nros2 run ros1_bridge parameter_bridge\n```\n\nIf all is well, the logging shows it is creating bridges for the topic and service and you should be able to call the service and listen to the ROS 1 talker from ROS 2:\n\n```bash\n# Shell E:\nsource ${ROS2_INSTALL_PATH}/setup.bash\nros2 run demo_nodes_cpp listener\n```\nThis should start printing text like `I heard: [hello world ...]` with a timestamp.\n\n```bash\n# Shell F:\nsource ${ROS2_INSTALL_PATH}/setup.bash\nros2 service call /add_two_ints example_interfaces/srv/AddTwoInts \"{a: 1, b: 2}\"\n```\nIf all is well, the output should contain `example_interfaces.srv.AddTwoInts_Response(sum=3)`\n\n### Parametrizing Quality of Service\nAn advantage of ROS 2 over ROS 1 is the possibility to define different Quality of Service settings per topic.\nThe parameter bridge optionally allows for this as well.\nFor some topics, like `/tf_static` this is actually required, as this is a latching topic in ROS 1.\nIn ROS 2 with the `parameter_bridge`, this requires that topic to be configured as such:\n\n```yaml\ntopics:\n  -\n    topic: /tf_static\n    type: tf2_msgs/msg/TFMessage\n    queue_size: 1\n    qos:\n      history: keep_all\n      durability: transient_local\n```\n\nAll other QoS options (as documented here in https://docs.ros.org/en/foxy/Concepts/About-Quality-of-Service-Settings.html) are available:\n\n```yaml\ntopics:\n  -\n    topic: /some_ros1_topic\n    type: std_msgs/msg/String\n    queue_size: 1\n    qos:\n      history: keep_last  # OR keep_all, then you can omit `depth` parameter below\n      depth: 10  # Only required when history == keep_last\n      reliability: reliable  # OR best_effort\n      durability: transient_local  # OR volatile\n      deadline:\n          secs: 10\n          nsecs: 2345\n      lifespan:\n          secs: 20\n          nsecs: 3456\n      liveliness: liveliness_system_default  # Values from https://design.ros2.org/articles/qos_deadline_liveliness_lifespan.html, eg. LIVELINESS_AUTOMATIC\n      liveliness_lease_duration:\n          secs: 40\n          nsecs: 5678\n```\n\nNote that the `qos` section can be omitted entirely and options not set are left default.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fros2%2Fros1_bridge","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fros2%2Fros1_bridge","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fros2%2Fros1_bridge/lists"}