Similarities
Similar Constructs
- Both are based on a graph of nodes, topics, and services. In ros2, the user graph looks like:
1
2
3
4
| ros2 node list
ros2 topic list
ros2 service list
ros2 action list
|
- Both have the same namespacing rules
/turtlesim
- Both provide node remapping:
ros2 run turtlesim turtlesim_node --ros-args --remap_node:=my_turtle. Then we can see our node under /my_turtle
- Be careful with the syntax
--ros-args --remap_node:
- Topic remapping:
ros2 run turtlesim turtle_teleop_key --ros-args --remap turtle1/cmd_vel:=turtle2/cmd_vel
Similar Packages
joint_state_publisherrqt is available
1
2
| sudo apt install ~nros-foxy-rqt*
rqt
|
ros2 run rqt_console rqt_console can be used to view logsros2 topic pub -r 1 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}" topic publishing is similar, too.
rviz2
- Make sure the RobotModel display is added to RViz to visualize the robot.
- In RViz, go to Displays > Add.
- Select RobotModel.
- This should visualize the robot if robot_description is set correctly.
Basic Differences
- C++ Standard: ROS1 uses C++03, C++11 is prevalent. ROS 2 uses C++ 11 and C++ 14.
- Python Standard: ROS: Python2, ROS 2: Python 3.5+
- Build systems: ROS 1 packages must be
cmake packages. Now ROS2 package can be a plain python packge as well. They can use everything in setup.py files, e.g., entrypoints since they are being invoked with python3 setup.py install
CLI Differences
- ROS2:
source install/setup.bash, ROS1: source devel/setup.bash
- ROS2:
colcon_cd <package>, ROS1: roscd <package>
- If you can’t find the
colcon_cd command, do source /usr/share/colcon_cd/function/colcon_cd.sh
Ros2 Params
ros2 param list /robot_state_publisher. This will give a list of ros2 paramsros2 param get /robot_state_publisher robot_description to get a single ros parameter server.
Key Package Differences
DDS
- Middleware:
- ROS1: custom serialization format, a custom transport protocol as well as a custom central discovery mechanism (TCPROS)
- ROS2: existing middleware interface, DDS. There are multiple DDS implementations. ROS has a unified interface for these implementations
- In DDS, each ROS 1 node is equivalent to a DDS “participant”. There could be multiple ROS nodes in the same process. Each node is still a DDS participant
- Under the hood, there are DDS datareader, datawriter, and DDS topics. They are not exposed to ROS users
1
2
3
4
5
6
7
8
9
10
11
| +-----------------------------------------------+
| user land | No middleware implementation specific code
+-----------------------------------------------+
| ROS client library |
+-----------------------------------------------+
| middleware interface | No DDS specifics
+-----------------------------------------------+
| DDS adapter 1 | DDS adapter 2 | DDS adapter 3 |
+---------------+---------------+---------------+
| DDS impl 1 | DDS impl 2 | DDS impl 3 |
+---------------+---------------+---------------+
|
1
2
3
4
5
6
7
8
9
| +----------------------+
| user land | 1) create a ROS message
+----------------------+ v
| ROS client library | 2) publish the ROS message
+----------------------+ v
| middleware interface | Translate to middleware data format
+----------------------+ v
| mw impl N | 3) convert the ROS message into a DDS sample and publish the DDS sample
+----------------------+
|
1
2
3
4
5
6
7
8
| | user land | 3) use the ROS message
+----------------------+ ^
| ROS client library | 2) callback passing a ROS message
+----------------------+ ^
| middleware interface | Translate to middleware data format
+----------------------+ ^
| mw impl N | 1) convert the DDS sample into a ROS message and invoke subscriber callback
+----------------------+
|
QOS: Some DDS QOS parameters are exposed to ROS2: (TODO)
Message Generation
IDL: TODO
