In this post you will see how to launch very easily a simulation in Gazebo with human crowd simulation and your most loved robot: Jetbot! This will be used as starting point for the next videos for doing people recognition, tracking, navigation and much more.
In order to follow the post, you must have the following rosject:
First thing after having the dekstop running, open a webshell and launch the simulation with the command below:
roslaunch jetdog_examples pedestrians_1.launch
Open gazebo and you must have the simulation running. Notice the robot lies on the origin of the world, one of the wall corners.
Check data available from the simulation in RViz
Open the graphical tools and maximize RViz. The people moving around should be visible in RViz, that’s because gazebo itself is publishing such information.
At this moment, the camera should be centralized using the topic that controls it, execute the command below:
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.
![[ROS2 Q&A] 222 – How to use hidden /cmd_vel topic with ros1_bridge](https://www.theconstruct.ai/wp-content/uploads/2022/01/222-How-to-use-hidden-topics-with-ros1_bridge.jpeg)
![[ROS2 Q&A] 226 – Work with ROS2 turtlesim](https://www.theconstruct.ai/wp-content/uploads/2022/01/01-turtlesim-1.png)
![[ROS Q&A] 225 – Setup your ROS2 Workspace with Unlimited Node Files](https://www.theconstruct.ai/wp-content/uploads/2021/12/04-result-1.png)
![[ROS2 Q&A] 224 – How to source ROS1 & ROS2 side by side](https://www.theconstruct.ai/wp-content/uploads/2021/12/224-How-to-source-ROS1-ROS2-side-by-side.jpeg)
![[ROS2 Q&A] 219 – How to Detect Obstacles in ROS2 Foxy with TurtleBot3](https://www.theconstruct.ai/wp-content/uploads/2021/12/219-How-to-Detect-Obstacles-in-ROS2-with-TurtleBot3.jpg)
