In this ROS LIVE-Class we’re going to show how to create a Gazebo plugin for a robot simulated world. The plugin will allow us to connect/disconnect the light of the world by means of a ROS topic. The plugin will be created using C++.
We will use the simulation we created on the previous Live Class of a wheeled robot on a home room. Do not worry, you will receive the code of the simulation at the beginning of this Live Class (only provided to those who attend live to the class. The code will be provided during the first 5 minutes of the class, so be in time).
We will see: ▸ Which types of Gazebo plugins exist ▸ How to create a world plugin that allows you to control anything in the simulated world (very useful for Reinforcement Learning) ▸ How to add ROS to the plugin so we can use it from our ROS programs.
Every Tuesday at 18:00 CET/CEST. This is a LIVE Class on how to develop with ROS. In Live Classes you practice with the teacher in real time, at the same time that he explains the lesson with the provided free ROS material.
IMPORTANT: Remember to be on time for the class because at the beginning of the class we will share the code with the attendants.
IMPORTANT 2: in order to start practicing quickly, we are using the ROS Development Studio the practice. You will need a free account to attend the class. Go to http://rds.theconstructsim.com and create an account prior to the class. Otherwise you will not be able to practice during the class.
In this Live Class we are going to see how to apply all that we have learnt in the previous classes about Gazebo. We are going to execute ARIAC simulation made by the OSRF. We are going to learn how to manage that simulation in order to make the robots perform useful tasks in the environment. We will indicate where Gazebo plugins were applied, how SDF was used to create the environment, were ROS control was applied, where ROS navigation was applied, etc. We will see how to create a simple Python program that allows us to make the robots do useful things.
A new ROS Live Class every Tuesday at 18:00 CET/CEST. This is a LIVE Class on how to develop with ROS. In Live Classes you practice with me at the same time that I explain, with the provided free ROS material.
IMPORTANT: Remember to be on time for the class because at the beginning of the class we will share the code with the attendants.
IMPORTANT 2: in order to start practicing quickly, we are using the ROS Development Studio for doing the practice. You will need a free account to attend the class. Go to http://rds.theconstructsim.com and create an account prior to the class.
In this video we are going to see how to create a Python script that stops a robot if no message is received in the /cmd_vel topic after a certain period of time.
This is a video trying to answer the following question posted at the ROS answers forum.
In this video we are going to see how to configure the differential drive ROS controller for a wheeled robot using a Gazebo simulation.
This is a video trying to answer the question of Jaime posted at the ROS answers forum about how he cannot make the controller work, and receiving the error:
Controller Spawner couldn’t find the expected controller_manager ROS interface
Step1. Create Project
Let’s start with creating a new project in ROS development studio.
Notice: If you haven’t had an account yet. You can register one here for free.
Step2. Spawn a robot
As an example, we’ll use a self-build two-wheel differential drive robot.
You can test the code with your own robot with differential drive configuration.
Step3. Add the controller configuration file for your robot
Put the configuration file(e.g. the my_diff_drive.yaml file shows here) under the config folder, your source tree may look like this.
Let’s start by pasting the whole code from the question into the my_diff_drive.yaml file.
mobile_base_controller:
type : "diff_drive_controller/DiffDriveController"
left_wheel : 'wheel_left_joint'
right_wheel : 'wheel_right_joint'
publish_rate: 50.0 # default: 50
pose_covariance_diagonal : [0.001, 0.001, 1000000.0, 1000000.0, 1000000.0, 1000.0]
twist_covariance_diagonal: [0.001, 0.001, 1000000.0, 1000000.0, 1000000.0, 1000.0]
# Wheel separation and diameter. These are both optional.
# diff_drive_controller will attempt to read either one or both from the
# URDF if not specified as a parameter
wheel_separation : 1.0
wheel_radius : 0.3
# Wheel separation and radius multipliers
wheel_separation_multiplier: 1.0 # default: 1.0
wheel_radius_multiplier : 1.0 # default: 1.0
# Velocity commands timeout [s], default 0.5
cmd_vel_timeout: 0.25
# Base frame_id
base_frame_id: base_footprint #default: base_link
# Velocity and acceleration limits
# Whenever a min_* is unspecified, default to -max_*
linear:
x:
has_velocity_limits : true
max_velocity : 1.0 # m/s
min_velocity : -0.5 # m/s
has_acceleration_limits: true
max_acceleration : 0.8 # m/s^2
min_acceleration : -0.4 # m/s^2
has_jerk_limits : true
max_jerk : 5.0 # m/s^3
angular:
z:
has_velocity_limits : true
max_velocity : 1.7 # rad/s
has_acceleration_limits: true
max_acceleration : 1.5 # rad/s^2
has_jerk_limits : true
max_jerk : 2.5 # rad/s^3
Step4. Create Launch file
For our case, the launch file should look something similar like this.
The args for the controller should have the same name in the .yaml file which is “mobile_base_controller”
According to the .yaml file, there is no namespace /robot here, so we don’t need to add this to the controller node.
Things to make sure:
The left wheel and right wheel in the .yaml file should be the same as your robot’s URDF definition.
The gazebo controller should be added to the URDF definition as well as the transmission tag which will be used for the gazebo controller. In our case, we add the following code in the .urdf to add gazebo control in it.
If you see the following topics, then your controller is up and run correctly.
Takeaway today:
The arg name of the controller node should be the same as in the controller configuration file.
Don’t specify robot namespace if you are not using it.
The joint name in the controller configuration file should be the same as the name in urdf
The gazebo_ros_control plugin should also be added to the urdf file.
Remember to compile again before you run.
If you want to learn more about ROS control and how to build a two-wheel robot in ROS from scratch, please visit Robot Ignite Academy for more information.
To visualize the robot model and laser scan, click add at the left bottom corner and select robot model and laser scan. Select topic /scan in the laser scan and make sure you choose a proper size.
Then we add two map visualization by clicking add and set one to visualize the global cost map and another to visualize the local cost map.
To visualize the path plan, we add two Path visualization. Notice: choose correct topics
Now if you close the Rviz, every setting you’ve done will disappear!
Step 3. Save Rviz settings
let’s create a package named husky_nav_rviz by type the following command under ~/catkin_ws/src directory
$ catkin_create_pkg husky_nav_rviz
and create a rviz folder under it.
Then we back to rviz and select File -> save config as to save the path_planning.rviz config file under the folder we just created.
You can close RViz once you are sure the path_planning.rviz is in the folder.
Step 4. Load Rviz settings
By select the path_planning.rviz file from File -> Open Config you can get all your settings back, or you can use the following command
In this video, we are answering a question about why the range sensor plugin for Gazebo is not detecting obstacles. The answer to that problem will surprise you !!! (ha, ha, ha).
In this posting, we will go through a demo of laser data visualization
NOTE: This article assumes that the audience is familiar with the following:
Running scripts on the terminal
Ros filesystem layout (what goes where launch dir, src dir etc)
RDS Environment (How to launch a project, how to navigate the directories.
Step – 3. Briefly skim through the code and run it
First, we go through the contents of package.xml (located inside the fakeLaserScan directory) which has the following content
(NOTE comments are removed in this reproduced code snippet for brevity)
This file contains various pieces of information about the project such as the package dependencies (roscpp, rospy, sensor_msgs, std_msgs) project name, version, license, maintainer etc. Some of this information is vital for building the project (like the dependencies). While other information is important from the perspective of sharing one’s work with the community.
In the given contents of the package.xml file, we notice that the project name specified in the file (beginner_tutorials) is different from the directory name (fakeLaserScanner). While this will not cause the project to crash but it is inconsistent with the project naming guideline.
Next, we take a look at the code inside fakeLaserScan.cpp
This code creates a publisher with the name fakeScan
The scan values are being generated inside a for loop (line 15-18 (excluding the blank lines))
These scan values are then copied to a LaserScan message (line 20, 32-35)
The message is being published at line 36. Also, note that the publish rate is 1 Hz (line 12)
As all seems okay we will go ahead and build the project. On the console browse to the catkin_ws directory and then run
$ catkin_make
This should proceed without any errors.
Next, we launch the project with the following command
$ roslaunch beginner_project fakeLaserScan.launch
This also should proceed without any errors.
Now we will open another console from the Tools menu and verify the topics with following commands
$ rostopic list
Outputs :
/fakeScan
/rosout
/rosout_agg
In the result, we see out topic /fakeScan appears. Further, we can check if the topic is publishing the correct information or not with the following command