In this post, you will learn how to replay ros2 bags with changed Quality of Service (QoS) setting. You’ll discover how to set the QoS before recording the bag, and how to change the QoS when playing back the bag file.
Step 1: Get a Copy of the ROS package containing the code used in the post
Click here to copy the project. It would be copied to your cloud account at The Construct. That done, open the project using the Run button. This might take a few moments, please be patient.
PS: If you don’t have an account on the The Construct, you would need to create one. Once you create an account or log in, you will be able to follow the steps to read and write parameters in ros1 and ros2.
You might also want to try this on a local PC if you have ROS installed. In that case you need to read on and duplicate the source code of the package in your own local workspace. However, please note that we cannot support local PCs and you will have to fix any errors you run into on your own.
Step 2: Start a simulation and the Quality of Service publisher
Open a web shell (1) and run the following commands to start a simulation:
Now start the QoS publisher in the same web shell (2) where you published to /cmd_vel. Note that we set the reliability to reliable. The QoS publisher publishes to the /robot_pose topic.
ros2 run qos_pose_publisher qos_pose_publisher -reliability reliable
Now let’s look at the reliability of the /robot_pose topic in a new web shell (3):
ros2 topic info /robot_pose --verbose
You should see something like this as part of the output:
Step 3: Record and play back a ros2 bag file of a topic
Now let’s record a ros2 bag file of a topic in web shell (3). We are using the /robot_pose topic.
ros2 bag record -o ros2bag_qos_as_published /robot_pose
Let it run for 5 seconds and then kill it, in web shell (3). You should have a new file created:
ros2bag_qos_as_published
Now let’s play the ros2 bag. But before that kill the qos_pose_publisher node in web shell (2) by pressing Ctrl+C. In the same web shell (2), run the following command:
ros2 bag play ros2bag_qos_as_published
Now let’s examine the QoS of the /robot_pose topic (now being published to from the ros2 bag), in web shell (3):
And that’s it! That’s how to replay ros2 bags with changed quality of service setting.
Step 5: Check your learning
Do you understand how to set the QoS for the topic before recording a bag?
Do you understand how to replay ros2 bags with changed quality of service setting?
If you didn’t get any of the points above, please go over the post again, more carefully this time.
(Extra) Step 6: Watch the video to understand how to create ros2 XML launch files
Here you go:
Feedback
Did you like this post? Do you have any questions about how to read and write parameters in ros1 and ros2? Whatever the case, please leave a comment on the comments section below, so we can interact and learn from each other.
If you want to learn about other ROS topics, please let us know in the comments area and we will do a video or post about it.
In this post, you will learn how to create ros2 XML launch files. You’ll discover how ros2 XML launch files are similar to and different from their ros1 counterparts.
Step 1: Get a Copy of the ROS package containing the code used in the post
Click here to copy the project. It would be copied to your cloud account at The Construct. That done, open the project using the Run button. This might take a few moments, please be patient.
PS: If you don’t have an account on the The Construct, you would need to create one. Once you create an account or log in, you will be able to follow the steps to read and write parameters in ros1 and ros2.
You might also want to try this on a local PC if you have ROS installed. In that case you need to read on and duplicate the source code of the package in your own local workspace. However, please note that we cannot support local PCs and you will have to fix any errors you run into on your own.
Step 2: Explore the source code using the IDE
Open the IDE by clicking on the icon as shown above. You should now see something similar to the image below:
The main file we will work with in this post is the one highlighted in red in the image above:
Double-click on the file in the IDE to open and study the contents. We will discuss this file in the following steps.
Step 3: Understand how to create ros2 XML launch files
Wait first! I thought ros2 launch files are only written in Python! Yes, Python is one of the options when writing ros2 launch files; we can also use XML files, especially if we are writing simple launch files that do not need to leverage Python’s powerful API.
On line 2, we define an argument (variable) use_sim_time with a default value of true.
On line 3, we include another launch file, turtlebot3_world.launch.py for launching the TurtleBot3 world. The launch file can be found in the turtlebot3_gazebo package.
On line 4, we pass a required argument use_sim_time to the included launch file, assigning it the value of the use_sim_time defined on line 2.
On line 6, we define a node to be started by the launch file. This node can be found in the package patrol_action_server, the node executable is patrol_action_server_exe and the name of the node would appear as patrol_action_server.
In short, this launch file launches the TurtleBot3 world and starts the Patrol action server. The same launch file can be written in Python, but this XML looks simpler and easier to understand. And it does all we want it to do, and we can even include Python-based launch files!
Step 4: Understand how ros2 XML launch files are similar to/different from ros1 XML launch files
If you are familiar with ros1 launch files, you should already notice some similarities:
The same <launch> tag.
Similar <arg> tag.
Familiar <include> tag.
Similar <node> tag.
Now if we were writing the same launch file in ros1, it would be something like this (PS: we can’t include ros2 launch file in a ros1 launch file in reality):
Did you like this post? Do you have any questions about how to read and write parameters in ros1 and ros2? Whatever the case, please leave a comment on the comments section below, so we can interact and learn from each other.
If you want to learn about other ROS topics, please let us know in the comments area and we will do a video or post about it.
In this post, you will learn how to read and write parameters in ros1 and ros2, using C++ nodes. You will see the slight differences in the ros1 and ros2 nodes and parameter files.
Step 1: Get a Copy of the ROS package containing the code used in the post
Click here to copy the project. It would be copied to your cloud account at The Construct. That done, open the project using the Run button. This might take a few moments, please be patient.
PS: If you don’t have an account on the The Construct, you would need to create one. Once you create an account or log in, you will be able to follow the steps to read and write parameters in ros1 and ros2.
You might also want to try this on a local PC if you have ROS installed. In that case you need to read on and duplicate the source code of the package in your own local workspace. However, please note that we cannot support local PCs and you will have to fix any errors you run into on your own.
Step 2: Explore the source code using the IDE
Open the IDE by clicking on the icon as shown above. You should now see something similar to the image below:
The six main files we will work with in this post are highlighted in red in the image above. These files are:
Double-click on each of the files in the IDE to open and study the contents. We will examine some of these files in the following steps.
Step 3: Understand how to read and write (load) parameters in ROS1
Now it’s time to see how to read and write parameters in ros1, working in the ros1 workspace.
Open a web shell and run the following commands:
cd ~/catkin_ws
source /opt/ros/noetic/setup.bash
source devel/setup.bash
roscore
The code block above changes to the ros1 workspace, sources it, and then starts the roscore (needed for ros1). Now let’s see a list of the current ros1 parameters available. Open another web shell and type the following:
But wait…are we getting the parameters in the YAML file (catkin_ws/src/yaml_parameters_ros1/config/params_demo_ros1.yaml) and their correct values? Let’s see what’s the in there!
Gosh, we are not getting these parameters nor their values, and you probably know why! So far we have been reading the parameters but have loaded them. Now let’s get that done: enter the launch file catkin_ws/src/yaml_parameters_ros1/launch/ros1_params_cpp_demo.launch.
Can you spot the differences between the formal and the latter outputs of these commands? Sure you can! So, well, that’s how to read and load parameter in ros1!
Step 4: Understand how to read and write (load) parameters in ROS2
Now let’s change to the ros2 workspace.
cd ~/ros2_ws
source /opt/ros/foxy/setup.bash
source install/setup.bash
In ros2 we need to have a node running before we can check for parameters, because there is no parameter server in ros2. Let’s try running the node then. The logic behind this node is contained in the ros2_ws/src/yaml_parameters/src/yaml_params_ros2.cpp file:
#include <rclcpp/rclcpp.hpp>
class MainNode : public rclcpp::Node {
public:
MainNode() : rclcpp::Node("node", rclcpp::NodeOptions()) {
// example: declare parameters, default value given
declare_parameter("param0", 1);
declare_parameter("param1", 0.1);
declare_parameter("param2", "default");
declare_parameter("param3.weight", 1);
declare_parameter("param3.name", "default");
declare_parameter("param4", false);
// example: declare a variable when declaring a parameter
declare_parameter("param5", std::vector<bool>(3, false));
declare_parameter("param6", std::vector<int64_t>(4, 1));
declare_parameter("param7", std::vector<double>(4, 0.1));
declare_parameter("param8", std::vector<std::string>(5, "default"));
// Get parameter values one by one
auto p0 = get_parameter("param0").as_int();
auto p1 = get_parameter("param1").as_double();
auto p2 = get_parameter("param2").as_string();
auto p3weight = get_parameter("param3.weight").as_int();
auto p3name = get_parameter("param3.name").as_string();
auto p4 = get_parameter("param4").as_bool();
auto p5 = get_parameter("param5").as_bool_array();
auto p6 = get_parameter("param6").as_integer_array();
auto p7 = get_parameter("param7").as_double_array();
auto p8 = get_parameter("param8").as_string_array();
// Print parameters
RCLCPP_INFO(get_logger(), "Integer parameter: %ld", p0);
RCLCPP_INFO(get_logger(), "Double parameter: %f", p1);
RCLCPP_INFO(get_logger(), "String parameter: %s", p2.c_str());
RCLCPP_INFO(get_logger(), "Nested integer parameter: %ld", p3weight);
RCLCPP_INFO(get_logger(), "Nested string parameter: %s", p3name.c_str());
RCLCPP_INFO(get_logger(), "Boolean parameter: %d", p4);
RCLCPP_INFO(get_logger(), "Boolean vector parameter [0]: %d",
static_cast<int>(p5[0]));
RCLCPP_INFO(get_logger(), "Integer vector parameter [0]: %d",
static_cast<int>(p6[0]));
RCLCPP_INFO(get_logger(), "Double vector parameter [0]: %f",
static_cast<double>(p7[0]));
RCLCPP_INFO(get_logger(), "String vector parameter [0]: %s", p8[0].c_str());
}
};
int main(int argc, char **argv) {
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<MainNode>());
rclcpp::shutdown();
return 0;
}
No, we are not :(. But not to worry, the launch file ros2_ws/src/yaml_parameters/launch/yaml_parameters.launch.py comes to the rescue! Let’s examine its content.
#!/usr/bin/env python3
import os
from launch import LaunchDescription
from launch_ros.actions import Node
from ament_index_python.packages import get_package_share_directory
def generate_launch_description():
return LaunchDescription([
Node(
package='yaml_parameters',
executable='main_node',
name='parameter_types_example',
parameters=[os.path.join(
get_package_share_directory('yaml_parameters'),
'config', 'params_demo_ros2.yaml')],
output='screen'),
])
Oh my, it’s a Python! Let’s set it loose and see what happens! Stop the currently running program with Ctrl + C and run the following in its place and check that your output is similar.
The launch file simply loads the parameters in the YAML file and also runs the node we run earlier.
Well, that’s it!
Step 5: Check your learning
Do you understand how to read and write parameters in ros1 and ros2, using C++ nodes?
Did you notice the slight differences in the format of the YAML files for ros1 and ros2?
Did you notice that you the ros2 parameters are tied to specific nodes vs existing in a parameter server in ros1?
If you didn’t get any of the points above, please go over the post again, more carefully this time.
Extra Step: Watch the video to understand how to read and write parameters in ros1 and ros2
Here you go:
Feedback
Did you like this post? Do you have any questions about how to read and write parameters in ros1 and ros2? Whatever the case, please leave a comment on the comments section below, so we can interact and learn from each other.
If you want to learn about other ROS topics, please let us know in the comments area and we will do a video or post about it.
Let’s assume you wish to wash your clothing. There are two possible ways you could go about it:
Go to the Laundry service provider
Put your clothes to wash.
Wait until the clothes are washed.
Get your clothes.
If you have a washing machine at home:
Put your clothes to wash
Instead of waiting, you can do other things and leave the watching machine doing its jobs
Check once in a while if the clothes are finished
Do other things.
Clothes are washed.
Option 1 is a blocking activity because you have to wait (in theory not able to do anything else) for the clothes to be washed, while option 2 is non-blocking because you can do some other things while your clothes are being washed.
This non-blocking is what defines an Action. If ROS2 Services are for instant request-responses, an Action is a task that may take a lot of time to be finished, and in the meantime, a robot (or you) is free to do other things and is also able to constantly check the status of the action.
Opening the rosject
In order to learn how to create an and use an Action Server in ROS2, we need to have ROS2 installed in our system, and it is also useful to have some simulations. To make your life easier, we already prepared a rosject with a simulation for that: https://app.theconstructsim.com/#/l/4a1c58c5/.
You can download the rosject on your own computer if you want to work locally, but just by copying the rosject (clicking the link), you will have a setup already prepared for you.
After the rosject has been successfully copied to your own area, you should see a Run button. Just click that button to launch the rosject (below you have a rosject example).
Learn ROS2 – Run rosject (example of the RUN button)
After pressing the Run button, you should have the rosject loaded. Let’s now head to the next section to really get some real practice.
Launching the simulation
The rosject we provided contains the packages needed to run a TurtleBot3 simulation in ROS2. The TurtleBot3 has the following sensors:
Lidar
IMU
Feel free to use this rosject to test your mobile robot programs.
The rosject is structured the following way:
turtlebot3_ws: this workspace contains the TurtleBot3 packages provided by ROBOTIS. Don’t modify this unless you know what you are doing and want to change something from the simulation
Use this workspace to develop your programs
Assuming you have opened the rosject by clicking the Run button, we can launch the simulation with:
After a few seconds, the simulation should have opened automatically:
[ROS2 How-to] #2 – Create a ROS2 action server – Simulation running
In case the simulation does not pop up automatically, you can easily click the Open Gazebo button like in the example below (bear in mind that the simulation below is not the one used in this tutorial. Its main purpose is to show the Open Gazebo button):
Open Gazebo by clicking Open Gazebo
Creating our ROS2 package (later used to create our Action Server)
Let’s create our ROS2 Package. For that, let’s start by opening a new terminal:
Open a new Terminal
In the terminal that was just open, by running the “ls” command you can see that we have at least the following folders:
ros2_ws turtlebot3_ws
The turtlebot3_ws contains the simulation, and the ros2_ws is where we are going to place our code.
Before you continue, it is worth mentioning that in the rosject that we shared with you, the custom_interfaces package that we are going to create here already exists. We are going to create it here basically for learning purposes. You would actually not need it since the package was already created for you:
Let’s create a package named custom_interfaces with the action_msgs std_msgs rosids_default_generators packages as dependencies:
After the package was created, let’s create a folder called action:
mkdir -p custom_interfaces/action/
and also create the action/Patrol.action file.
touch custom_interfaces/action/Patrol.action
This is the file/Interface that we will use in our Action Server for patrolling.
Let’s now open that Patrol.action file. You can open it in the Code Editor. If you do not know how to open the Code Editor, please check the image below:
Open the IDE – Code Editor
You can now open the custom_interfaces/action/Patrol.action file and paste the following content on it:
In the end, the final CMakeLiss.txt file would look like the following:
cmake_minimum_required(VERSION 3.8)
project(custom_interfaces)
if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
add_compile_options(-Wall -Wextra -Wpedantic)
endif()
# find dependencies
find_package(ament_cmake REQUIRED)
find_package(action_msgs REQUIRED)
find_package(std_msgs REQUIRED)
find_package(rosidl_default_generators REQUIRED)
set(action_files
"action/Patrol.action"
)
rosidl_generate_interfaces(${PROJECT_NAME}
${action_files}
DEPENDENCIES action_msgs std_msgs
)
if(BUILD_TESTING)
find_package(ament_lint_auto REQUIRED)
# the following line skips the linter which checks for copyrights
# uncomment the line when a copyright and license is not present in all source files
#set(ament_cmake_copyright_FOUND TRUE)
# the following line skips cpplint (only works in a git repo)
# uncomment the line when this package is not in a git repo
#set(ament_cmake_cpplint_FOUND TRUE)
ament_lint_auto_find_test_dependencies()
endif()
ament_package()
And for the file custom_interfaces/package.xml we also have to add the following code before the <export> tag:
So far so good. ROS is able to find our custom interface.
The time has now come for us to create the Action Server.
Creating our ROS2 Action Server
Let’s create a different package for the Action Server, just to keep things separated. Since we are not doing to create Interfaces in this new package, just use existing interfaces, let’s use the ament_python build type. Again, bear in mind that if you are using the rosject that we provided, the package already exists in the ~/ros2_ws/src folder:
Let’s now open that file using the Code Editor, and paste the following content to it:
#!/usr/bin/env python3
#
# Copyright 2019 ROBOTIS CO., LTD.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# Authors: Ryan Shim, Gilbert
import math
import time
import rclpy
from geometry_msgs.msg import Twist
from rclpy.action import ActionServer
from rclpy.action import CancelResponse
from rclpy.action import GoalResponse
from rclpy.callback_groups import ReentrantCallbackGroup
from rclpy.duration import Duration
from rclpy.node import Node
from rclpy.qos import QoSProfile
from rclpy.executors import MultiThreadedExecutor
from custom_interfaces.action import Patrol
class Turtlebot3PatrolServer(Node):
def __init__(self):
super().__init__('turtlebot3_patrol_server')
self.goal = Patrol.Goal()
qos = QoSProfile(depth=10)
# Initialise publishers
self.cmd_vel_pub = self.create_publisher(Twist, 'cmd_vel', qos)
# Initialise servers
self._action_server = ActionServer(
self,
Patrol,
'patrol',
execute_callback=self.execute_callback,
callback_group=ReentrantCallbackGroup(),
goal_callback=self.goal_callback,
cancel_callback=self.cancel_callback)
self.get_logger().info("Turtlebot3 patrol action server has been initialised.")
def destroy(self):
self._action_server.destroy()
super().destroy_node()
def goal_callback(self, goal_request):
# Accepts or rejects a client request to begin an action
self.get_logger().info('Received goal request :)')
self.goal = goal_request
return GoalResponse.ACCEPT
def cancel_callback(self, goal_handle):
# Accepts or rejects a client request to cancel an action
self.get_logger().info('Received cancel request :(')
return CancelResponse.ACCEPT
async def execute_callback(self, goal_handle):
self.get_logger().info('Executing goal...')
radius = self.goal.radius # unit: m
speed = 0.5 # unit: m/s
feedback_msg = Patrol.Feedback()
total_driving_time = 2 * math.pi * radius / speed
feedback_msg.time_left = total_driving_time
last_time = self.get_clock().now()
# Start executing an action
while (feedback_msg.time_left > 0):
if goal_handle.is_cancel_requested:
goal_handle.canceled()
self.get_logger().info('Goal canceled')
return Patrol.Result()
curr_time = self.get_clock().now()
duration = Duration()
duration = (curr_time - last_time).nanoseconds / 1e9 # unit: s
feedback_msg.time_left = total_driving_time - duration
self.get_logger().info('Time left until the robot stops: {0}'.format(feedback_msg.time_left))
goal_handle.publish_feedback(feedback_msg)
# Give vel_cmd to Turtlebot3
twist = Twist()
twist = self.drive_circle(radius, speed)
self.cmd_vel_pub.publish(twist)
# Process rate
time.sleep(0.010) # unit: s
# When the action is completed
twist = Twist()
self.cmd_vel_pub.publish(twist)
goal_handle.succeed()
result = Patrol.Result()
result.success = True
self.get_logger().info('Returning result: {0}'.format(result.success))
return result
def drive_circle(self, radius, velocity):
self.twist = Twist()
self.linear_velocity = velocity # unit: m/s
self.angular_velocity = self.linear_velocity / radius # unit: rad/s
self.twist.linear.x = self.linear_velocity
self.twist.angular.z = self.angular_velocity
return self.twist
def main(args=None):
rclpy.init(args=args)
patrol_action_server = Turtlebot3PatrolServer()
# Use a MultiThreadedExecutor to enable processing goals concurrently
executor = MultiThreadedExecutor()
rclpy.spin(patrol_action_server, executor=executor)
patrol_action_server.destroy()
rclpy.shutdown()
if __name__ == '__main__':
main()
The code used above is just an adaptation of a code already provided by ROBOTIS.
Before we compile our code, we also have to open the patrol_action_server/setup.py file and modify the entry_points section to define our executable called patrol_action_server_exe in the following way:
We can now run our server with the following commands:
source install/setup.bash
ros2 run patrol_action_server patrol_action_server_exe
The server should start with no problems:
[INFO] [1651528559.914166370] [turtlebot3_patrol_server]: Turtlebot3 patrol action server has been initialised
Calling our ROS2 Action Server
Ok, if you did not kill the Action Server launched in the previous section, please open a second terminal that we will use to call the Action Server.
With “ros2 node list” we should be able to find our node running:
ros2 node list
/turtlebot3_patrol_server
And with ros2 action list, we should be able to see the /patrol action:
ros2 action list
/patrol
We can now call our Action Server. If you remember when we created the Patrol.action, we defined a radius. Let’s them call the Action Server passing a radius of 0.5. The robot will be basically rotating:
You should now see the feedback sent by the action server:
Waiting for an action server to become available...
Sending goal:
radius: 0.5
Goal accepted with ID: dd32bc835d7a4ef5ae854d0bfb4b119f
Feedback:
time_left: 6.2831525802612305
Feedback:
time_left: 6.271763801574707
Feedback:
time_left: 6.260392665863037
Feedback:
time_left: 6.2484917640686035
Feedback:
time_left: 6.237414836883545
Feedback:
time_left: 6.2265496253967285
Feedback:
time_left: 6.215761661529541
...
^CCanceling goal...
Feedback:
time_left: 5.634908676147461
Goal canceled.
Remember that you can easily cancel the call to the action server by pressing CTRL+C.
If you look at the simulation after sending a goal to the Action Server, you should see the robot spinning around 0.5 meters.
Congratulations. You now know how to create a ROS2 Action Server from scratch. If you want more details about the code of the Action Server, please check the video in the next section.
Youtube video
So this is the post for today. Remember that we have the live version of this post on YouTube. If you liked the content, please consider subscribing to our youtube channel. We are publishing new content ~every day.
Keep pushing your ROS Learning.
Related Courses & Training
If you want to learn more about ROS and ROS2, we recommend the following courses:
In this post, we will see how to program drones using ROS2. Perhaps you have programmed drones using ROS1, found that programming drones using ROS2 is not as straightforward, and have been wondering, “how the heck do you program drones using ROS2?” You have come to the right place!
Step 1: Grab the required source code
You can program drones using ROS2 on your local PC by following the instructions in this repository step by step. However if you use the rosject you copied below, we have already done most of the heavy lifting for you and you just need to run a few commands to get your drone flying!
Click here to get your own copy of the project (PS: If you don’t have an account on the ROS Development Studio, you would need to create one. Once you create an account or log in, we will copy the project to your workspace).
That done, open the project using the Run button. This might take a few moments, please be patient.
Step 2: Understand the basic components
The ros2 drone system used in this post consists of three main parts:
A ros2 simulation containing the simulation and the plugin that connects to the rest of the system.
cd ~/ros2_ws
source install/setup.bash
ros2 launch ls2n_drone_simulation single_drone_trajectory_sitl.launch.py
By this time, you should have the simulation running. Open the Gazebo app (if not opened automatically) to see it. Right click on the drone model on the left pane and select “Follow” to keep seeing the drone when it takes off.
Now, open another web shell and start the PX-4 system:
cd ~
cd px4-autopilot/Tools/
./gazebo_sitl_multiple_run_only_px4.sh
Finally, start the ground control system in another web shell:
user:~$ cd squashfs-root/
user:~/squashfs-root$ ./AppRun
The ground control GUI should load shortly. Open the Graphical Tools app to see it, if not opened automatically:
Time to take off the drone!
Ensure the top-left corner of the controller says “Ready to Fly” in a green background.
Click the Takeoff button on the top left.
In the bottom middle, drag the slider to the right to confirm takeoff. You should see something similar to the image below.
If the takeoff does not work, repeat 2 & 3.
After takeoff, the button changes to “Land”. Use it to land the drone.
Step 4: Consolidate your learning
Do you understand how to program drones using ROS2 after watching the video? If not, please review the material again and perhaps go over the video again. Let us know any problems you are seeing in the comments.
Extra Step: Watch the video for the sights and sounds version of how to program drones using ROS2
Did you like this post? Do you have any questions about the explanations? Whatever the case, please leave a comment on the comments section below, so we can interact and learn from each other. If you want to learn about other ROS2 topics, please let us know in the comments area and we will do a video or post about it.