In order to learn how to use hidden topics with ros1_bridge, let’s start by creating a rosject (ROS project). We are going to use The Construct (https://www.theconstruct.ai/) for this tutorial, but if you have ROS2 installed on your own computer, you should be able to do ~everything on your own computer, except this creating a rosject part.
Let’s start by opening The Construct (https://www.theconstruct.ai/) and logging in. You can easily create a free account if you still don’t have one.
Once inside, let’s create My Rosjects and then, Create a new rosject:
My Rosjects
Create a new rosject
For the rosject, let’s select ROS2 Foxyfor the ROS Distro, let’s name the rosject as Turtlebot3 hidden topics. You can leave the rosject public.
If you mouse over the recently created rosject, you should see a Run button. Just click that button to launch the rosject.
Turtlebot3 hidden topics in ROS2
Cloning the required repositories with the simulations
After we have created our rosject and opened it, let’s now open a web shell as we can see in the image below:
Open a new Web Shell/Terminal
After that, let’s enter into the ~/simulation_ws/src directory and clone three repositories there with the following commands:
Once we have correctly cloned the repositories that contain the simulation and ROS messages needed to simulate Turtlebot with ROS, we now need to start the simulation.
The rosject that we created comes by default with ROS2 Noetic and ROS2 Foxy installed.
In order to test the simulation in ROS2, let’s first launch it with ROS1 to make sure the simulation is working properly at least in ROS1. We will then use ROS1 Bridge to be able to see the topics in ROS2.
Let’s start by sourcing ros1 noetic with, and sourcing our simulation_ws/devel folder as follows:
cd ~/simulation_ws
source /opt/ros/noetic/setup.bash
source devel/setup.bash
After having sourced the workspace that contains the simulation, we should now be able to launch it with the following commands:
Now that the simulation has been launched, we can open gazebo in order to see it. For that, hover your mouse over the button that has the icon of gazebo and click Open Gazebo. After that, you should be able to see the turthebot3 simulation in ROS1, which means the simulation is well defined, and the meshes are correct.
Open Gazebo by clicking Open Gazebo
Launching ROS1 Bridge
Let’s start by sourcing the ros workspaces in order. Let’s start by sourcing ROS1, then ROS2, and finally, run the bridge. For that, open a second web shell and type the following:
source /opt/ros/noetic/setup.bash
source /opt/ros/foxy/setup.bash
ros2 run ros1_bridge dynamic_bridge --bridge-all-topics
If everything went well, you should have seen some logs like the following:
created 1to2 bridge for topic '/clock' with ROS 1 type 'rosgraph_msgs/Clock' and ROS 2 type 'rosgraph_msgs/msg/Clock'
created 1to2 bridge for topic '/gazebo/link_states' with ROS 1 type 'gazebo_msgs/LinkStates' and ROS 2 type 'gazebo_msgs/msg/LinkStates'
created 1to2 bridge for topic '/gazebo/model_states' with ROS 1 type 'gazebo_msgs/ModelStates' and ROS 2 type 'gazebo_msgs/msg/ModelStates'
created 1to2 bridge for topic '/imu' with ROS 1 type 'sensor_msgs/Imu' and ROS 2 type 'sensor_msgs/msg/Imu'
created 1to2 bridge for topic '/joint_states' with ROS 1 type 'sensor_msgs/JointState' and ROS 2 type 'sensor_msgs/msg/JointState'
created 1to2 bridge for topic '/odom' with ROS 1 type 'nav_msgs/Odometry' and ROS 2 type 'nav_msgs/msg/Odometry'
created 1to2 bridge for topic '/rosout' with ROS 1 type 'rosgraph_msgs/Log' and ROS 2 type 'rcl_interfaces/msg/Log'
created 1to2 bridge for topic '/rosout_agg' with ROS 1 type 'rosgraph_msgs/Log' and ROS 2 type 'rcl_interfaces/msg/Log'
created 1to2 bridge for topic '/scan' with ROS 1 type 'sensor_msgs/LaserScan' and ROS 2 type 'sensor_msgs/msg/LaserScan'
created 1to2 bridge for topic '/tf' with ROS 1 type 'tf2_msgs/TFMessage' and ROS 2 type 'tf2_msgs/msg/TFMessage'
Created 2 to 1 bridge for service /gazebo/clear_body_wrenches
Created 2 to 1 bridge for service /gazebo/clear_joint_forces
Created 2 to 1 bridge for service /gazebo/delete_light
Created 2 to 1 bridge for service /gazebo/delete_model
Created 2 to 1 bridge for service /gazebo/get_joint_properties
Created 2 to 1 bridge for service /gazebo/get_light_properties
Created 2 to 1 bridge for service /gazebo/get_link_properties
Created 2 to 1 bridge for service /gazebo/get_link_state
Created 2 to 1 bridge for service /gazebo/get_model_properties
Created 2 to 1 bridge for service /gazebo/get_model_state
Created 2 to 1 bridge for service /gazebo/get_physics_properties
Created 2 to 1 bridge for service /gazebo/get_world_properties
Created 2 to 1 bridge for service /gazebo/pause_physics
Created 2 to 1 bridge for service /gazebo/reset_simulation
Created 2 to 1 bridge for service /gazebo/reset_world
Created 2 to 1 bridge for service /gazebo/set_joint_properties
Created 2 to 1 bridge for service /gazebo/set_link_properties
Created 2 to 1 bridge for service /gazebo/set_link_state
Created 2 to 1 bridge for service /gazebo/set_model_configuration
Created 2 to 1 bridge for service /gazebo/set_model_state
Created 2 to 1 bridge for service /gazebo/set_physics_properties
Created 2 to 1 bridge for service /gazebo/spawn_sdf_model
Created 2 to 1 bridge for service /gazebo/spawn_urdf_model
Created 2 to 1 bridge for service /gazebo/unpause_physics
Created 2 to 1 bridge for service /imu_service
[INFO] [1641212256.136511189] [ros_bridge]: Passing message from ROS 1 rosgraph_msgs/Clock to ROS 2 rosgraph_msgs/msg/Clock (showing msg only once per type)
[INFO] [1641212256.138899978] [ros_bridge]: Passing message from ROS 1 gazebo_msgs/LinkStates to ROS 2 gazebo_msgs/msg/LinkStates (showing msg only once per type)
created 2to1 bridge for topic '/gazebo/link_states' with ROS 2 type 'gazebo_msgs/msg/LinkStates' and ROS 1 type 'gazebo_msgs/LinkStates'
[INFO] [1641212256.140508214] [ros_bridge]: Passing message from ROS 1 gazebo_msgs/ModelStates to ROS 2 gazebo_msgs/msg/ModelStates (showing msg only once per type)
created 2to1 bridge for topic '/rosout' with ROS 2 type 'rcl_interfaces/msg/Log' and ROS 1 type'rosgraph_msgs/Log'
[INFO] [1641212256.141466301] [ros_bridge]: Passing message from ROS 1 sensor_msgs/Imu to ROS 2sensor_msgs/msg/Imu (showing msg only once per type)
[INFO] [1641212256.142755982] [ros_bridge]: Passing message from ROS 1 sensor_msgs/JointState to ROS 2 sensor_msgs/msg/JointState (showing msg only once per type)
removed 2to1 bridge for topic '/gazebo/link_states'
[INFO] [1641212256.144608098] [ros_bridge]: Passing message from ROS 1 nav_msgs/Odometry to ROS2 nav_msgs/msg/Odometry (showing msg only once per type)
[INFO] [1641212256.146602236] [ros_bridge]: Passing message from ROS 1 tf2_msgs/TFMessage to ROS 2 tf2_msgs/msg/TFMessage (showing msg only once per type)
[INFO] [1641212256.160265245] [ros_bridge]: Passing message from ROS 2 rcl_interfaces/msg/Log to ROS 1 rosgraph_msgs/Log (showing msg only once per type)
[INFO] [1641212256.466793392] [ros_bridge]: Passing message from ROS 1 sensor_msgs/LaserScan toROS 2 sensor_msgs/msg/LaserScan (showing msg only once per type)
[INFO] [1641212256.469177152] [ros_bridge]: Passing message from ROS 1 rosgraph_msgs/Log to ROS2 rcl_interfaces/msg/Log (showing msg only once per type)
Checking the /cmd_vel topic
Now that ros1_bridge is up and running, let’s open a third terminal and list the ros2 topics with:
ros2 topic list
You should have seen at least the following topics:
If we look carefully at the list of topics above, we cannot see any /cmd_vel topic. But the topic exists in ROS1. To ensure the topic exists in ROS1, let’s open a fourth terminal and list the topics with:
source /opt/ros/noetic/setup.bash
rostopic list
The list should contain something like the output below, showing that indeed we have a topic called /cmd_vel (the second one in the list below).
And this is what confuses some users. How is that /cmd_vel is available in ros1 but it is not available on ros2? Well, we still do not have a definite answer on why this happens, but we know that if in ROS2 we start publishing in that topic, it will be received by ROS1 and the robot will move accordingly, even though we are not able to see the topic with ros2 topic list. Let’s try that.
First, if we were to publish messages in the /cmd_vel topic using ROS1, the command would be as follows (you do not need to run the command below):
For ros2, the message instead of geometry_msgs/Twist would be geometry_msgs/msg/Twist. Since ros2 does not auto-complete because it does not know the /cmd_vel topic, we can copy the auto-completed values for geometry_msgs/Twist in ROS1 and pass it to ros2.
Let’s go back to the third terminal where ROS2 Foxy is sourced by default and run the following command:
As you can see, with ROS2 we are able to move the robot that is running with ROS1, even if we cannot list the topic with ros2.
By looking at the logs of the second web shell, where ros1_bridge was launched, we can also confirm that the message is being correctly interchanged from the ROS2 to the ROS1 /cmd_vel topic:
created 2to1 bridge for topic '/cmd_vel' with ROS 2 type 'geometry_msgs/msg/Twist' and ROS 1 type ''
[INFO] [1641214498.129565691] [ros_bridge]: Passing message from ROS 2 geometry_msgs/msg/Twistto ROS 1 geometry_msgs/Twist (showing msg only once per type)
removed 2to1 bridge for topic '/cmd_vel'
created 2to1 bridge for topic '/cmd_vel' with ROS 2 type 'geometry_msgs/msg/Twist' and ROS 1 type ''
So, that is it. We just learned that even when some topics are not visible in ROS2 through ros1_bridge, we can still publish messages on them using ROS2.
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.
In this post it will be shown how to work with Turtlesim with ROS 2, one of the best ways of testing ROS2 features with a very simple simulation
Configuring environment
In order to do that in a way anyone can reproduce, let’s use the App of TheconstructSim. Start by creating a new rosject here
After creating it, just hit the Run button and wait for the desktop environment to get ready.
Launch turtlesim simulation
Start by opening a web shell and executing the following command:
ros2 run turtlesim turtlesim_node
You must have some logs in the shell and the simulation ready in the graphical tools, like the image below:
Control using the keyboard
In order to control the robot using the teleop keyboard, we must check if the topics match. In that case, turtlesim has a namespace and the teleop keyboard must be re-mapped.
Check the topics of the simulator:
ros2 topic list
In that case, we need to map the keyboard to the topic /turtle1/cmd_vel
This is quite simple by using the cli, just run the node adding an argument, like below:
ros2 run teleop_twist_keyboard teleop_twist_keyboard cmd_vel:=/turtle1/cmd_vel
This is a quick way to start working with mobile robots. You can try many different algorithms quickly without having to configure a more complex simulation.
In this post it will be shown how to organize your ROS2 package in such manner that allows you to have as many python scripts as you need. It is a quite simple way of doing it, but can be confusing for those who are coming from ROS 1. Let’s check it out!
Configuring environment
In order to do that in a way anyone can reproduce, let’s use the App of TheconstructSim. Start by creating a new rosject here
After creating it, just hit the Run button and wait for the desktop environment to get ready.
Create the ROS package
With the environment ready, create a new ROS 2 package inside the given workspace. Use the commands below:
You must be able to edit the files from the IDE at this point:
Go to the root workspace:
Compile the package
Source the workspace
Check that your package is added to ROS environment
cd ~/ros2_ws
colcon build
source install/setup.bash
ros2 pkg list | grep pkg1
Add some code to the scripts to have some nodes
Add the code below to the hello_world.py script:
import rclpy
from rclpy.node import Node
class MyNode(Node):
def __init__(self):
# call super() in the constructor in order to initialize the Node object
# the parameter we pass is the node name
super().__init__('hello_world')
# create a timer sending two parameters:
# - the duration between 2 callbacks (0.2 seeconds)
# - the timer function (timer_callback)
self.create_timer(0.2, self.timer_callback)
def timer_callback(self):
# print a ROS2 log on the terminal with a great message!
self.get_logger().info("Hello World!")
def main(args=None):
# initialize the ROS communication
rclpy.init(args=args)
# declare the node constructor
node = MyNode()
# pause the program execution, waits for a request to kill the node (ctrl+c)
rclpy.spin(node)
# shutdown the ROS communication
rclpy.shutdown()
if __name__ == '__main__':
main()
And the same for the goodbye_world.py, just changing the info text
import rclpy
from rclpy.node import Node
class MyNode(Node):
def __init__(self):
# call super() in the constructor in order to initialize the Node object
# the parameter we pass is the node name
super().__init__('hello_world')
# create a timer sending two parameters:
# - the duration between 2 callbacks (0.2 seeconds)
# - the timer function (timer_callback)
self.create_timer(0.2, self.timer_callback)
def timer_callback(self):
# print a ROS2 log on the terminal with a great message!
self.get_logger().info("Goodbye World!")
def main(args=None):
# initialize the ROS communication
rclpy.init(args=args)
# declare the node constructor
node = MyNode()
# pause the program execution, waits for a request to kill the node (ctrl+c)
rclpy.spin(node)
# shutdown the ROS communication
rclpy.shutdown()
if __name__ == '__main__':
main()
Create a launch file
In order to run both scripts at the same time, let’s create a launch file:
cd ~/ros2_ws/src
touch pkg1/launch/hello_goodbye.launch
chmod +x pkg1/launch/hello_goodbye.launch
In order to add the launch file to the setup, it must contain some libraries like os and glob. The content of the file ~/ros2_ws/src/pkg1/setup.py will look like below:
In order to learn how to create conditional publishers, let’s start by creating a publisher and a subscriber in Python. We are going to use The Construct (https://www.theconstruct.ai/) for this tutorial, but if you have ROS2 installed on your own computer, you should be able to do ~everything on your own computer, except this creating a rosject part.
Let’s start by opening The Construct (https://www.theconstruct.ai/) and logging in. You can easily create a free account if you still don’t have one.
Once inside, let’s create My Rosjects and then, Create a new rosject:
My Rosjects
Create a new rosject
For the rosject, let’s select ROS2 Foxyfor the ROS Distro, let’s name the rosject as ROS Q&A 224. You can leave the rosject public.
If you mouse over the recently created rosject, you should see a Run button. Just click that button to launch the rosject.
Checking enviroment configuration
Open a webshell and go to the installation folder of ROS, like shown below:
You can see there are installed two ROS distros, ROS 1 Noetic and ROS 2 Foxy
That means both systems are installed, like the user shown his workspace. Now, open the code editor and check the workspaces:
There are two main workspaces, catkin_ws (for ROS noetic) and ros2_ws (for ROS 2 foxy)
Configuring an environment with both setups
The quickest way to have a ROS environment with both ROS and ROS2 is by creating a new workspace. In the webshell, execute the following:
Open in the IDE the file ~/new_ros2_ws/install/setup.bash. This is a fresh new ROS2 workspace, it does not have ROS noetic attached to it. It is shown in the image below, no ROS commands (e.g: roscore) are available:
You can have as many ROS 2 workspaces as you want and the fresh new workspace built does not have the setup to attache ROS 1 to it, unless you configure to do so.
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.
In order to detect obstacles in ROS2 with TurtleBot3, let’s start by creating a rosject. We are going to use The Construct (https://www.theconstruct.ai/) for this tutorial, but if you have ROS2 installed on your own computer, you should be able to do ~everything on your own computer, except this creating a rosject part.
Let’s start by opening The Construct (https://www.theconstruct.ai/) and logging in. You can easily create a free account if you still don’t have one.
Once inside, let’s create My Rosjects and then, Create a new rosject:
My Rosjects
Create a new rosject
For the rosject, let’s select ROS2 Foxyfor the ROS Distro, let’s name the rosject as Turtlebot3 Obstacle Detection. You can leave the rosject public.
Turtlebot3 Obstacle Detection rosject for ros2
If you mouse over the recently created rosject, you should see a Run button. Just click that button to launch the rosject.
Cloning the Turtlebot3 repositories
Once the rosject is open, let’s start by cloning the necessary repositories.
Let’s open a new terminal by clicking on the Open a new shell window button:
Open a new shell
After having a web shell open, let’s enter our ros2_ws/src folder:
cd ~/ros2_ws/src
Let’s now source our ROS Foxy environment with:
source /opt/ros/foxy/setup.bash
It is worth mentioning that this source command has to be executed in all web shells that you open. If you want to automatically run that command for every shells, just add it to the .bashrc with:
Now that the simulation was launched, we could open Gazebo by clicking the Gazebo button as we can see in the image below:
Turtlebot3 Obstacle Detection rosject – Open Gazebo
Launching the teleop keyboard
Now that the simulation is up and running, let’s run the teleop keyboard in oder to easily move the robot around.
For that, let’s open another web shell. After that, let’s source our environment:
cd ~/ros2_ws
source install/setup.bash
export TURTLEBOT3_MODEL=burger
ros2 run turtlebot3_teleop teleop_keyboard
You should now be able to move the robot around by pressing the keys as instructed in your web shell, using the keys w, a, s, d, and x.
Moving around:
w
a s d
x
Launching the Object Detector
Awesome. Now we have our simulation running, the keyboard teleoperator running, it is now time to run our Object Detector.
For that, let’s open a new terminal (the third one). After having it open, let’s source our workspace again:
cd ~/ros2_ws
source install/setup.bash
export TURTLEBOT3_MODEL=burger
ros2 run turtlebot3_example turtlebot3_obstacle_detection
The obstacle detection should now be working properly. It should output something similar to the following:
[INFO] [1638920304.914586963] [turtlebot3_obstacle_detection]: Turtlebot3 obstacle detection node has been initialised.
Since it may be subscribed to the /cmd_vel_raw topic, let’s kill the keyboard teleop launched in the second terminal, and run it again as follows (using the /cmd_vel_raw topic):
export TURTLEBOT3_MODEL=burger
ros2 run turtlebot3_teleop teleop_keyboard /cmd_vel:=/cmd_vel_raw
If you now move next to the wall, the terminal where the Obstacle Detector node was launched, you should see some messages saying that an obstacle was detected. Something similar to:
[INFO] [1638920462.116441990] [turtlebot3_obstacle_detection]: Obstacles are detected nearby. Robot stopped.
[INFO] [1638920462.126177608] [turtlebot3_obstacle_detection]: Obstacles are detected nearby. Robot stopped.
[INFO] [1638920462.136174240] [turtlebot3_obstacle_detection]: Obstacles are detected nearby. Robot stopped.
[INFO] [1638920462.146231079] [turtlebot3_obstacle_detection]: Obstacles are detected nearby. Robot stopped.
[INFO] [1638920462.160709358] [turtlebot3_obstacle_detection]: Obstacles are detected nearby. Robot stopped.
Congratulations. You now know how to detect obstacles with Turtlebot3 using ROS2.
Youtube video
So this is the post for today. Remember that we have the live version of this post on YouTube (important: the video uses the ROS Dashing version, but it may help you anyway). If you liked the content, please consider subscribing to our youtube channel. We are publishing new content ~every day.
In order to learn how to create conditional publishers, let’s start by creating a publisher and a subscriber in Python. We are going to use The Construct (https://www.theconstruct.ai/) for this tutorial, but if you have ROS2 installed on your own computer, you should be able to do ~everything on your own computer, except this creating a rosject part.
Let’s start by opening The Construct (https://www.theconstruct.ai/) and logging in. You can easily create a free account if you still don’t have one.
Once inside, let’s create My Rosjects and then, Create a new rosject:
My Rosjects
Create a new rosject
For the rosject, let’s select ROS2 Foxyfor the ROS Distro, let’s name the rosject as Battery Level Node. You can leave the rosject public.
Battery Level Node – Conditional Publisher in ROS2
If you mouse over the recently created rosject, you should see a Run button. Just click that button to launch the rosject.
Writing a simple publisher and subscriber (Python)
Once the rosject is open, we can now create our publisher and subscriber. For that, we are going to use ROS Docs as a reference.
Let’s open a new terminal by clicking on the Open a new shell window button:
Open a new shell
Once the terminal is open, we can list the files with the ls command:
user:~$ ls
ai_ws catkin_ws notebook_ws ros2_ws simulation_ws webpage_ws
We can see a workspace named ros2_ws. Let’s enter that workspace using cd ros2_ws/:
user:~$ cd ros2_ws/
user:~/ros2_ws$
Let’s now source our workspace with:
source ~/ros2_ws/install/setup.bash
Let’s now enter our src folder:
cd ~/ros2_ws/src/
And create a package named py_pubsub (python publisher and subscriber):
Be aware that in order to create this package, we basically used ROS Docs for reference.
If you now list your src folder using ls, you should be able to see our package:
user:~/ros2_ws/src$ ls
py_pubsub
We can now enter into this py_pubsub package using cd py_pubsub/. We will find a new folder named py_pubsub inside it. Let’s just enter into it. The full command would be as easy as cd ~/ros2_ws/src/py_pubsub/py_pubsub/ . But if you want to go step by step:
user:~/ros2_ws/src$ cd py_pubsub/
user:~/ros2_ws/src/py_pubsub$ ls
package.xml py_pubsub resource setup.cfg setup.py test
user:~/ros2_ws/src/py_pubsub$ cd py_pubsub/
user:~/ros2_ws/src/py_pubsub/py_pubsub$ ls
__init__.py
user:~/ros2_ws/src/py_pubsub/py_pubsub$
Now inside that last py_pubsub folder, let’ download a publisher and a subscriber named publisher_member_function.py and subscriber_member_function.py respectively. Bear in mind that up to this point we are basically following the docs aforementioned:
cd ~/ros2_ws/src/py_pubsub/py_pubsub
wget https://raw.githubusercontent.com/ros2/examples/foxy/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py
wget https://raw.githubusercontent.com/ros2/examples/foxy/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py
We should now have three files inside our py_pubsub folder/package:
cd ~/ros2_ws/src/py_pubsub/py_pubsub; ls
__init__.py publisher_member_function.py subscriber_member_function.py
Let’s now open the publisher_member_function.py using the Code Editor:
ROS2 Publisher
Let’s modify the timer_callback method of the publisher_member_funcion.py, so that instead of increasing the initial value, let’s decrease it. Let’s also modify our constructor (__init__ method) to make the initial value of the i variable be 100.
What this means is that the i variable will initially have the value 100, then it is going to decrease it. The final content of the publisher_member_funcion.py file should be similar to the following:
# Copyright 2016 Open Source Robotics Foundation, Inc.
#
# 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.
import rclpy
from rclpy.node import Node
from std_msgs.msg import String
class MinimalPublisher(Node):
def __init__(self):
super().__init__('minimal_publisher')
self.publisher_ = self.create_publisher(String, 'topic', 10)
timer_period = 0.5 # seconds
self.timer = self.create_timer(timer_period, self.timer_callback)
self.i = 100
def timer_callback(self):
msg = String()
msg.data = 'Battery Level: %d' % self.i
self.publisher_.publish(msg)
self.get_logger().info('Publishing: "%s"' % msg.data)
self.i -= 1
def main(args=None):
rclpy.init(args=args)
minimal_publisher = MinimalPublisher()
rclpy.spin(minimal_publisher)
# Destroy the node explicitly
# (optional - otherwise it will be done automatically
# when the garbage collector destroys the node object)
minimal_publisher.destroy_node()
rclpy.shutdown()
if __name__ == '__main__':
main()
Now let’s open also our subscriber_member_function.py file and modify the listener_callback method so that it will have the following content:
What the changes are going to do is: if the battery level is between 70 and 66 %, then a warning message will be printed, and that warning will be published into a topic named /battery.
We also have to create the publisher into the constructor (__init__ method) with:
So in the end, the final subscriber will look like this:
# Copyright 2016 Open Source Robotics Foundation, Inc.
#
# 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.
import rclpy
from rclpy.node import Node
from std_msgs.msg import String
class MinimalSubscriber(Node):
def __init__(self):
super().__init__('minimal_subscriber')
self.subscription = self.create_subscription(
String,
'topic',
self.listener_callback,
10)
self.subscription # prevent unused variable warning
self.publisher_ = self.create_publisher(String, 'battery', 10)
def listener_callback(self, msg):
if msg.data in ['Battery Level: 70', 'Battery Level: 69', 'Battery Level: 68', 'Battery Level: 67', 'Battery Level: 66']:
self.get_logger().info('WARNING!: "%s"' % msg.data)
self.publisher_.publish(msg)
def main(args=None):
rclpy.init(args=args)
minimal_subscriber = MinimalSubscriber()
rclpy.spin(minimal_subscriber)
# Destroy the node explicitly
# (optional - otherwise it will be done automatically
# when the garbage collector destroys the node object)
minimal_subscriber.destroy_node()
rclpy.shutdown()
if __name__ == '__main__':
main()
Now that we have our publisher and subscriber, ready where the subscriber contains a conditional publisher, now open our package.xml file and add rclpy and std_msgs as dependencies, by adding the two lines below afterament_python:
The final result should be similar to the image below:
exec_depend rcl_py and std_msgs
Let’s now open the setup.py file and add our publisher and subscriber (let’s call them talker and listener respectively) to the entry_points. Our final entry_points should look like:
Now that our ros2_ws (ROS2 Workspace) is built, let’s run our publisher and subscriber to make sure they are working. Let’s start by running our publisher, that we named talker.
source ~/ros2_ws/install/setup.bash
ros2 run py_pubsub talker
If everything went ok, you should see something similar to this:
But, if you got an error message like this one “No executable found“, then it means you need to make your publisher and subscriber executables. You can make them executable with:
chmod +x ~/ros2_ws/src/py_pubsub/py_pubsub/*
You can now open a different web shell and run the subscriber named listener with:
source ~/ros2_ws/install/setup.bash
ros2 run py_pubsub listener
If the battery level is already below 66%, you should see no messages being published by the listener. If that is the case, please kill and start the talker again in the first terminal. You can kill it with CTRL+C , and can start it again just as you did before:
CTRL+C
ros2 run py_pubsub talker
After having restarted the talker in the first terminal, you can now keep an eye on the terminal where the listener was executed. When the battery level goes between 70 and 66%, the following message should have been printed.
Be aware that in order to see the message being published in the third terminal, where the /battery topic is being echoed, you have to restart the talker again, since the battery level at this point is well below the 65%.
Again, you can kill the talker in the first terminal with CTRL+C , and can start it again just as you did before:
CTRL+C
ros2 run py_pubsub talker
Now you should be able to see the output in the third terminal (/battery topic)
Congratulations. You made it. You now know not only how to create conditional publishers, but you have also learned how to create packages, and modify publishers and subscribers in ROS2 Python.
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.