ROS1 vs ROS2: writing your nodes

The ROS API – rclcpp, rclpy

In ROS1, for Cpp you use roscpp, and for Python, rospy. Both libraries are completely independent and built from scratch. It means that the API is not necessarily the same between roscpp and rospy, and some features are developed for one, and not the other.

ROS2 has more layers. There is only one base library, named rcl, and implemented in C. This is the foundation which contains all of the ROS2 core features.

You won’t use the rcl library directly in your programs. You’ll use another client library built on top of rcl. For example: rclcpp for Cpp, rclpy for Python.

For you, as a developer, it means that:

• The API between rclcpp and rclpy will be much more similar than the API between roscpp and rospy.

• It will be easier to create and use other language client libraries, for example rclnodejs, rcljava, etc. No need to reinvent the wheel, you just need to make a C binding with rcl. And all clients in all languages will have a similar API.

• When a new core feature is released, it will be available sooner in different languages, so you won’t have to wait too much.

Python and Cpp versions

As you may know, Python2 is not supported anymore. Well in fact, to provide a smoother transition, it’s still supported for Ubuntu 18 and ROS1 Melodic until their EOL (2023).

ROS1 Noetic targets Python3, as well as all ROS2 versions.

Now, for Cpp, there is some great progress. ROS1 was targeting Cpp 98, and you could use Cpp 11/14 in later ROS1 versions, provided that it didn’t break other dependencies.

In ROS2 you can now use Cpp 11 and 14 by default. Cpp 17 is also on the roadmap. That’s great because new versions of Cpp introduce many useful functionalities, making development easier, quicker, and safer. Also, it makes Cpp more fun, and maybe this will help democratize this powerful and great language (well it seems I’m biased).

Writing a node (with OOP)

In ROS1 there is no specific structure telling you how you should write your node functionalities. You can decide to add callback functions anywhere in your program, or use OOP if you wish to, but every one’s implementation could be unique.

In ROS2 things are different. There is a convention about how to write your nodes. You have to create a class which inherits from the Node object (for example: rclcpp::Node in Cpp, rclpy.node.Node in Python). In this class you’ll have all your ROS2 functionalities.

This is great because it will save everyone a lot of time. You already have a good, modular structure for writing your node. It will make your programs cleaner, and cooperation between developers on different projects will be easier.

Check out how to write a minimal ROS2 Python node, and a ROS2 Cpp node, with OOP.

Using OOP for your nodes in ROS2 also allows you to convert them to components, which is a new feature in ROS2. Let’s see that now.

Multiple nodes in the same executable – ROS2 Components

In ROS1 a node is tight to an executable. A new functionality, named Nodelets, was added in ROS1 to be able to write multiple nodes in the same executable, with intra-process communication. This is really great when you have limited hardware resources and/or you need to send a lot of messages between nodes.

In ROS2, Nodelets are not called Nodelets anymore. The functionality has been directly included in the ROS2 core, and is now called “components”.

So, with ROS2, you can handle many nodes from the same executable, using components. A component is simply a slightly modified node class (we’re still using OOP there).

Then, you can start your components from a launch file, the terminal, or from an executable. And you can activate intra-process communication to remove any ROS2 communication overhead.

Building components is a good practice to create efficient ROS2 applications.

Lifecycled nodes

ROS2 introduces the concept of lifecycled nodes. A lifecycled node has different states: unconfigured, inactive, active, finalized. This is very useful when you need a setup phase before actually running your node’s main functionalities.

When you start such a node it is initially unconfigured. Through the provided interface (ROS2 services), you can ask for a transition to another state. When you do that a predefined callback will be triggered inside the node.

Let’s say you have a node for a sensor. You first need to make sure the sensor is detected, and the communication has been successfully started. Then you can start your reading loop and publish the data.

With a lifecycled node you can clearly separate this: first you allocate memory for publishers, subscribers, and other instantiated objects. Then, you initiate the communication with the sensor. And finally you run your reading loop to publish the data.

Writing launch files

Launch files allow you to start all your nodes from one file. You can start a standard node, a component, a lifecycled node. You can add arguments, parameters, and many other options.

In ROS1, you’ve been used to write launch files with XML.

In ROS2 you will now use Python to write your launch files. There is an API allowing you to start nodes, retrieve config files, add parameters, etc. And it will allow you to customize your launch files much more than before.

However, is writing a launch file in Python really new? Well in fact no. In ROS1 there is also a Python API. The problem is: no one is aware of it, and there’s almost zero documentation about it. So, no one uses it. And it became quite the norm to write launch files in XML, which is great, but certainly not as modular as with the Python API.

And… You can also write your ROS2 launch files with XML if you want to. But prefer using Python, as it brings more modularity, is more documented, and has become the ROS2 convention for launch files.

Check out how to write a ROS2 launch file.

ROS1 vs ROS2: Communication

No more ROS master

One thing you’ve learned with ROS1: always start a ROS master before you run a node. The ROS1 master will act as a DNS server for your nodes, so they can retrieve each other.

In ROS2, no more ROS master! This is no more a centralized system. Each node has the capacity to discover other nodes. You can simply start a node without having to worry if you have a master running or not.

This change is great because it allows you to create a fully distributed system. Each node is independent and not tight to a global master.

When creating a multi-machine ROS2 application, you won’t have to define one machine as the “master”. Each machine will be independent and able to start on its own, connect and disconnect with each other, with less setup than in ROS1.

Parameters

So, in ROS1, parameters are handled by the parameter server, which is itself handled by… The ROS master.

In ROS2, no more ROS master = no more (global) parameter server.

The concept of parameters has been completely changed. There is no global parameter anymore. Each parameter is specific to a node.

A node declares and manages its own parameters, and those parameters are destroyed when the node is killed.

It’s like each node has its own parameter server. When you start a node a few ROS2 services are created. Those allow you to interact with its parameters from the terminal or from other nodes.

In addition, you can easily modify a node’s parameters after they’ve been created, using a parameter callback.

If you were using the dynamic_reconfigure tool in ROS1, well, good news, now this is part of the core functionalities. No more extra config, all you need is to bind a parameter callback to your node.

Check out how to handle Parameters in your code: rclcpp params and rclpy params.

Services

In ROS1, services are synchronous. When your service client asks a request to the server, it is stuck until the server responds (or fails).

In ROS2, services are asynchronous.

When you call a service, you can add a callback function which will be triggered when the server responds. In the meantime your main thread is not stuck.

And of course, if you want you can also use services synchronously.

Actions

In ROS1, actions were never in the core functionalities. It was an addition made after a few years, to solve the problem that services were not asynchronous, and did not have a feedback or cancelation mechanism.

So, actions in ROS1 are entirely built on top of ROS1 topics.

In ROS2, actions are now part of the ROS2 core. The API for Cpp and Python is quite similar as for ROS1, so no problem with the code.

Underneath, actions still use topics for feedback and goal status, but also (asynchronous) services for setting a goal, canceling a goal, and requesting a result.

And now, actions also have their own command line tool! As you would do with a service, you can now send an action goal to a server, directly from the terminal.

Messages, Services, and Action definitions

The way to create definitions for messages, services, and actions is quite similar in ROS1 vs ROS2. You still put them into msg/, srv/, and action/ folders.

But after you compile them, a namespace is added:

• Message: msg/…
• Services: srv/…
• Actions: action/…

For example, let’s say you have a package named my_robot_msgs, and inside this package you have created a message named Temperature, plus a service named ActivateButton. In your node’s code you’ll have to import them using:

• my_robot_msgs/msg/Temperature.
• my_robot_msgs/srv/ActivateButton.

This is great because it reduces the confusion, and makes the separation clearer between all 3 types of communications.

QoS

ROS2 introduces QoS, or Quality of Service.

With that feature you can choose how your nodes handle communication: do you want to make sure you receive all messages? Or is it OK to lose a few messages, as long as the data is frequently updated? Do you want to keep a queue of messages in case a node doesn’t have the time to process them all, or do you want to drop any new message if a callback for a previous message is still running?

Well, if you have to ask such questions for your application, then you’ll need to tune QoS for your nodes.

By default, the QoS for ROS2 communication (topics, services, …) has been chosen so you can expect the same behavior as in ROS1:

• Any node subscribing to a topic won’t receive previous messages, only messages published after subscribing.
• Like TCP, messages are guaranteed to be delivered.
• You can set a queue size for delivered messages waiting to be processed.

If you have to deal with a lossy wireless network, and/or a large message bandwidth, QoS is a setting worth looking at.

But if you’re just getting started with ROS, or have a very simple application, don’t worry about QoS. There are more important things to learn first, and you will come back to QoS when you need it.

ROS1 vs ROS2: Packages, workspace and environment

Building your nodes

The build system in ROS1 is catkin. You use “catkin_make” or “catkin build” in order to build and install your packages.

In ROS2, no more catkin. Ament is the new building system, and on top of that you get the colcon command line tool.

To compile, you’ll use the command “colcon build” in your ROS2 workspace.

There is much more to say about ament and colcon, but with just this information you’ll be able to build your first nodes without any problem.

Command line tools

Most of the command line tools are similar between ROS1 and ROS2. The name of the tools, and some options are different, but otherwise there is no big difference when you use them.

For example, to list all topics, in ROS1 you’d do “rostopic list”, and in ROS2 ros2 topic list. “rosservice” becomes ros2 service, “rosrun” becomes ros2 run, “rosbag” becomes ros2 bag, etc.

You just have to write “ros2”, followed by the name of the tool you want to use.

Cpp and Python packages

With ROS1, you create a package and then you add any Cpp/Python file you want.

ROS2 makes the difference between a Cpp and a Python package. When creating the package from the command line, you have to specify one build type: ament_cmake or ament_python.

Depending on that argument, the package architecture won’t be the same.

For a Cpp package, things are quite similar with ROS1. You still have a CMakeLists.txt. You just have to adapt your cmake instructions to use ament and not catkin.

For a Python package, things are different: you have some new files, such as setup.py and setup.cfg. The setup.py replaces the CMakeLists.txt. You can of course directly run your Python scripts, but if you want to start them from ROS2 command line tools or a launch file, you’ll have to install them first (with “colcon build”).

You can also, if you want to, create a ROS2 package for both Python and Cpp, but this requires a little bit more setup.

Overall, setting packages up in ROS2 is a little bit more complex than in ROS1, but it’s also more complete, and better organized.

Sourcing workspace and overlays

Sourcing your ROS environment is not so much different between ROS1 and ROS2. You first source your global ROS installation, then your workspace, and you can use your custom code.

ROS2 brings the concept of overlays. You can have multiple workspaces on top of each other.

First you source your global ROS installation, then your first workspace (overlay), your second overlay, etc. If a package has the same name in a lower level overlay and a higher level overlay, then only the higher level one will be used.

When you develop your application and already have a certain number of packages, you can create an overlay for just one package. This will allow you to quickly iterate on it, while keeping your code base unchanged for other projects.

With this technique you can also override a package which is already installed from binaries. This is very practical so you can keep the package installed, while having your own version for a specific application.

OS support

ROS1’s main target is Ubuntu.

Great news for ROS2: thanks to its new architecture, you can install and use it on Ubuntu, MacOS, and Windows 10 (+ other OSes, but those are the 3 main ones).

This will make ROS2 more accessible and more embeddable in many applications.

For example, you could have a mobile robot with Raspberry Pi and Ubuntu, and another computer using Windows for a 3D simulation tool and a driver node for a camera scanning the scene. And all of that running smoothly together.

When to switch from ROS1 to ROS2?

Well, it’s not as simple as that, and many people will tell you different answers. ROS1 is still strong, with many stable plugins, more documentation and 3rd party plugins. Eventually it will end, but you still have a few years before that.

If you’re new to ROS (whether ROS1 or ROS2), then you should probably learn ROS2 fundamentals. But then it can also be interesting to get a taste of ROS1 too. Why? Because you may understand some things in ROS2 better if you also see how it’s done in ROS1. And also, some tools/packages you want to use may not yet be ported to ROS2, so you’ll have no choice but to use the ROS1 version of the package. In this case the ros1_bridge package will be useful (see next section).

If you already know ROS and want to start a brand new project, then going the ROS2 way is probably what you should do, so it means less transition work in the future. The core concepts between ROS1 and ROS2 are similar, so the more experienced you are with ROS1, the less time you’ll take to learn ROS2. You can also use ROS1 and ROS2, hand in hand with ros1_bridge, in order to use missing tools and plugins.

If you already have a code base in ROS1 for one or more of your robots, or for a complete organization with dozens of developers, switching to ROS2 may represent a lot of work. The bigger the code base and the influence of ROS on your project, the longer it will take, and the more complex it will be. You may choose to continue working with ROS1 for legacy projects, and start working with ROS2 for new projects. Or you could start porting all your code to ROS2 now, knowing that there’s a lot of work involved (depending on how well your code is written). First, before you decide to make the complete switch, make sure that most of the ROS features you need have been ported to ROS2. Again, ros1_bridge may help you during the transition.

Using ROS1 and ROS2 together with the ros1_bridge package

If you need to work with an existing ROS1 code base, but want to develop new features with ROS2, then you are not necessarily stuck.

You can use the ROS2 package named ros1_bridge, which will make, as its name suggests, a bridge between ROS1 and ROS2 communications.

Even if the concepts are the same between ROS1 and ROS2, the communication underneath is not directly compatible, and some adaptation is required. The ros1_bridge package provides that.

When doing a transition to ROS2, you can start porting a few packages in ROS2, and make those packages communicate with the rest of your ROS1 application. Then, you port more and more packages until there is nothing left written with ROS1. During all the porting time, your application can still work as expected.

ROS1 vs ROS2: Conclusion

In this article you’ve seen some of the major differences between ROS1 and ROS2. I tried to make the approach focused on the practical side, so you can get an overview of what’s changing for you, when you develop a robotics application with ROS.

To stay informed, you can check the ROS Discourse forums, where you’ll see interesting discussions about new concepts, debates and announcements.

Now, the list presented here is certainly not exhaustive and some information is subject to change, because ROS2 is still evolving a lot. But it’s a good starting point to see what you need to focus on, when you decide to learn ROS2.

Changes between ROS 1 and ROS 2

Platforms

• ROS 1 is only being CI tested on Ubuntu. It is actively supported by the community on other Linux flavors as well as OS X

• ROS1 보안적인 문제도 있음

• ROS 2 is currently being CI tested and supported on Linux(Ubuntu), Window, Mac

Language

• The core of ROS 1 is targeting C++03 and supports up to C++11.
• ROS 2 uses C++11 extensively and uses some parts from C++14. In the future ROS 2 might start using C++17 as long as it is supported on all major platforms.

Python

• ROS 1 is targeting Python 2. ROS 2 requires at least Python version 3.5.

Reusing existing middleware

• ROS 1 uses a custom serialization format, a custom transport protocol as well as a custom central discovery mechanism. ROS 2 has an abstract middleware interface, through which serialization, transport, and discovery is being provided. Currently all implementations of this interface are based on the DDS standard. This enables ROS 2 to provide various Quality of Service policies which improve communication over different networks.

• ROS1 uses custom setup based on HTTP for communication

• ROS2 uses Data Distributed system(DDS) for communication

Build system

Support other build systems beside CMake

• Every ROS package is a CMake project. In ROS 2 other build systems can be easily supported. For now the build tool supports plain Python packages beside CMake.

Python packages

• In ROS 1 a package with Python code can only use a small subset of the features available in setup.py files since the setup.py file is being processed by custom logic from within CMake. In ROS 2 a Python package can use anything in setup.py files, e.g. entry points since they are being invoked with python3 setup.py install.

Environment setup

• In ROS 1 the build tool generates scripts which must be sourced in order to setup the environment before being able to use the built ROS packages. This approach only works when the ROS packages are being built with ROS specific build tool.

• In ROS2 the environment setup is separated into package-specific scripts and workspace-specific scripts. Each package provides the necessary scripts to make itself usable after being built. The build tool only invokes the workspace-specific scripts which then call the package-specific scripts.

No non-isolated build

• In ROS 1 multiple packages can be built in a single CMake context. While this speeds up the build step, every package needs to ensure that cross package target dependencies are defined correctly. Additionally all packages share the same namespace which leads to colliding target names, etc.

• In ROS 2 only isolated builds are supported, i.e. every package is built separately on its own. The install spaces can be either isolated or merged.

No devel space

• In ROS 1 packages can be built without installing them. From the devel space in combination with the source space the system is already usable. But every package has to actively support the devel space, e.g. in environment hooks and CMake code.

• In ROS 2 a package must be installed after building it before it can be used.

• One reason for the devel space in ROS 1 is to enable the developer to change files, e.g. Python code or launch files, and use the modified code directly without the need to rebuild the package. This benefit is preserved in ROS 2 by optionally replacing copy operations in the install steps with symlinks.

Support catkin_simple use case

• in ROS 1 the package catkin_simple is aiming to make writing the CMake code of ROS packages easier. In many cases it is not achieving this goal which is often due to restrictions of the design necessary for support features like the devel space.

• In ROS 2 the CMake API was restructured to support this use case.

Minimal support for packages without manifest

• In ROS 1 only packages with a manifest file are considered by the build system. In ROS 2 it is possible to detect packages with supported build system in folders without a manifest file. If the package follows common practice it might even be possible to detect some of the missing meta information (like dependencies).

Messages, Services

Separated namespaces in C++

• In ROS 1 .msg and .srv files can have the same name but the generated code collides. The same is the case for the request and response parts of services.

• In ROS 2 the generated code uses separate namespaces to guarantee it is collision-free.

Same names in Python

• The generated Python code for messages and service is currently using the same module and class names in ROS 1 and ROS 2. Therefore they can not be imported both in a single application. This decision might be revisited if required.

Optional default values in message definitions

• In ROS 2 primitive values in messages can now have default values, set when the message is constructed. Default values for non-primitive fields, i.e. array of strings, nested messages, are not yet possible

Optional upper bounds for arrays and strings

• This is necessary in order to calculate the maximum size of a message in memory, which allows for preallocation of messages with a dynamic sizes. This is useful for performance and for use cases like real-time.

Unify duration and time types

• In ROS 1 the duration and time types are defined in the client libraries. The member names of the data structures are different in C++ (sec, nsec) and Python (secs, nsecs).

• In ROS 2 these types are defined as messages and therefore are consistent across languages.

Remove sequence field from Header message

• The field has been deprecated for a long time and was not set consistently in ROS 1.

Client libraries

Across languages

Topic namespaces

• Currently ROS 2 does not support namespaces in topic names. This is mostly due to restrictions of valid characters in DDS topic names. A design document describes how this should be added in the future.

Notifications

• In ROS 1 all information about the ROS graph must be polled from the master. In ROS 2 changes will be published instead, e.g. notifications if a parameter has been changed.

Components with life cycle

• In ROS 1 every node usually has its own main function. In ROS 2 it is recommended to subclass from a component which has a life cycle.

• The life cycle can be used by tools like roslaunch to start a system composed of many components in a deterministic way

Parameters and Dynamic Reconfigure

• In ROS 1 global parameters and node-specific dynamic reconfigure parameters are two separate concepts. In ROS 2 a unified approach is being used. It is similar to dynamic reconfigure and a node named “global parameter server” (⏳) will accept requests to set values unconditionally. In ROS 1 all this information needs to be polled for changes in ROS 2 changes will be published to notify other entities.

Actions

• ROS 2 currently doesn’t have the concept of actions. It will be added in the future as a combination of a preemptable server and a feedback publisher.

Threading model

• In ROS 1 the developer can only choose between single-threaded execution or multi-threaded execution. In ROS 2 more granular execution models are available in C++ (e.g. across multiple nodes) and custom executors can be implemented easily. For Python the execution models haven’t been implemented yet.

ROS Graph

• In ROS 1 nodes and topics can be remapped at startup time only. In ROS 2 support for remapping hasn’t been implemented yet (⏳). The goal is to enable remapping as well as aliasing not only during startup time but also during runtime.

In ROS 1 node names are unique and this is being enforced by shutting down existing nodes when a new node with the same name is started. In ROS 2 the uniqueness of node names is not yet enforced.

C and C++

Support for real-time

• ROS 1 does not support writing real-time code but relies on external frameworks like Orocos. In ROS 2 it will be possible to write real-time nodes when using a proper RTOS and with carefully written user code.

C++

Node vs. Nodelet

• In ROS 1 the API’s for nodes and nodelets are different and requires the developer to decide the mapping of nodes to processes at programming time. In ROS 2 it is recommended to compile each component into a shared library which can then be loaded in a separate process or share the same process with other components (like ROS 1 nodelets). This enables to choose the process layout at deploy-time.

Allow multiple nodes per process

• In ROS 1 it is not possible to create more than one node in a process. This is due to the API itself but also because of internal implementation decisions. In ROS 2 it it possible to create multiple nodes in a process.

Tools

roslaunch

• In ROS 1 roslaunch files are defined in XML with very limited capabilities. In ROS 2 launch file are written in Python which enables to use more complex logic like conditionals etc. The current state only provides minimal functionality to run tests using multiple processes.

Resource lookup

• In ROS 1 various resources (packages, messages, plugins, etc.) are looked up by crawling the file system based on the ROS_PACKAGE_PATH. This can cause poor performance when the trees in the ROS_PACKAGE_PATH are large, and caching produces inconsistent state.

• n ROS 2 resources can be registered at an index at compile time and then be queried efficiently at runtime. For more information please see the documentation of the resource index.

Packaging

ABI versioning

• ROS 1 rebuilds all downstream packages since it assumes ABI incompatibility. To avoid this significant overhead a ROS 2 package should be able to declare its ABI to avoid rebuilding downstream packages whenever possible

Binary packages for Windows

• ROS 1 can only be built from source on Windows (which also only works for a few ROS packages and is not supported). ROS 2 will provide binary package based on Chocolatey.

ROS1에서는 GAZEBO 혹은 Real Environment에 모바일로봇을 컨트롤 하려면 roscore을 통해 연결을 시켜줘야 했다(rosmaster). 그 이후 다른 터미널을 통해서 컨트롤을 해야 됐다.

즉 Roscore는 마스터 노드이며, 모든 노드는 이 마스터 노드에 종속이 되어 있다. 마스터 노드를 반드시 켜야만 다른 노드들을 이용할 수 있었다.

그러나 ROS2에서는 Roscore(Client/servr(or Slave/master) 형식) 아키텍처가 사라졌고. DDS(Data Distribbution service) 아키텍처가 적용이 되었다. (publish/subscribe 형식)

즉, peer to peer로 실시간과 다양한 데이터 타입을 효과적으로 교환할 수 있다. (ROS1에서는 roscore라는 중간다리가 있기 때문에 불필요한 코스트가 컷고, 노드간 frequency 문제가 있었다.)

또한 모든 노드가 마스터 노드에 종속이 되어 있기 떄문에, 어떤 노드가 문제가 생기게 될경우 모든 시스템에 실패를 불러오게 된다. 그렇지만 로스2에서는 어떤 노드가 문제가 생겼을 경우에도 시스템 실패가 아닌 버그로 간주하여 더 intuitive하게 문제를 해결할 수 있다.

예) 이전 roscore가 없다면

rostopic list 를 하였을 경우 리스트 결과가 안나왔을 것이다.

그러나 ROS2에서는 roscore에 존속되어있지 않기 때문에, 노드 런칭을 자유롭게 할 수있고 토픽이나 echo package 명령어를 통해 런칭된 노드에 있는 변수들을 확일 할 수 있다.

Overview

Gazebo is a stand-alone application which can be used independently of ROS or ROS 2. The integration of Gazebo with either ROS version is done through a set of packages called gazebo_ros_pkgs. These packages provide a bridge between Gazebo’s C++ API and transport system, and ROS 2 messages and services.

Not all functionality from ROS 1 has been ported to ROS 2 yet. You can check the progress on this issue.

If you're interested in porting official or your own custom plugins, check out the ROS2 migration contribution guide.

The ROS 2 package gazebo_ros_pkgs is a metapackage which contains the following packages:

• gazebo_dev: Provides a cmake configuration for the default version of Gazebo for the ROS distribution. So downstream packages can just depend on gazebo_dev instead of needing to find Gazebo by themselves.
• gazebo_msgs: Message and service data structures for interacting with Gazebo from ROS 2.
• gazebo_ros: Provides convenient C++ classes and functions which can be used by other plugins, such as gazebo_ros::Node, conversion and testing utilities. It also provides some generally useful plugins.
• gazebo_plugins: A series of Gazebo plugins exposing sensors and other features to ROS 2. For example, gazebo_ros_camera publishes ROS 2 images, and gazebo_ros_diff_drive provides an interface for controlling and instrospecting differential drive robots through ROS 2.

Differences from ROS 1

Several changes and refactoring were done to gazebo_ros_pkgs when migrating from ROS 1 to ROS 2.

Some goals of the refactoring were:

• take advantage of new ROS 2 features, such as masterless discovery.
• Remove code which duplicates functionality already present in Gazebo.
• Reduce duplication by standardizing common functionality, such as how to set ROS namespaces, parameters and topic remapping.
• Modernize the codebase, making use of the latest SDFormat, Gazebo and Ignition APIs, as well as ROS 2’s style guidelines and linters
• Add tests and demos for all ported functionality.

INT

The ROS 1 integration required that Gazebo be launched with the gazebo_ros_api_plugin system plugin, which would initialize ROS.

There’s no such requirement with ROS 2. Gazebo can be started without any plugins and ROS-2-enabled plugins can be added at runtime.

Node

in ROS 1, each plugin typically had one or more ros::NodeHandle instances to interact with ROS.

In ROS 2, plugins use gazebo_ros::Node instead, which allows each plugin to exist as its own node in the ROS graph, with its own parameters, namespace, loggers, etc. Plugins also don’t need to worry about spinning the node or keeping callback queues - gazebo_ros handles all that internally.

SDF parsing

There are several configurations which Gazebo ROS plugins commonly want to set through SDF, and in the ROS 1 implementation, there was a lot of duplicate code on plugins parsing the same things, sometimes following loose conventions.

In ROS 2, common configurations like namespace, ROS parameters and topic remapping rules are parsed by gazebo_ros::Node, so there’s no need for plugins to reimplement them every time.

사용방법

ROS1과 같다. terminal에서 바로 런치할 수 있고, 런치파일을 통해 GAZEBO_PACKAGE를 노드로 삼아 environment spawn하고 robot을 spawn을 하여서 사용할 수 있다. 다만 ros2의 launch 방식이 파이썬으로 바껴서 이것을 배워야한다.

Summarry

즉, 주로 중복된 코드와 파라미터 변수들을 줄였고, SDF에 있는 중복된 파라미터 및 변수를 줄였다. 즉 중복되는 변수와 파라미터들을 줄여 시스템 collision을 줄였다.

1. Source ROS1 Version bash file
2. Source ROS2 version bash file
3. Open another terminal and get ROSMASTER host number(echo $ROS_MASTER_URI) and (export rosmaster uri) at origin terminal
4. 얻은 rosmaster host number를 이전 터미널에 적용
5. ros1_bridge package를 통해 ros2에 사용하려는 robot package를 연결(현재 사용된 터미널은 이제 roscore로 사용하게 됨)
   • ros2 run ros1_bridge dynamic_bridge
6. 그리고 another terminal에서 런칭 및 코드, rosrun으로 로봇 조작 가능.