This is the third part of a video that shows how to release a ROS2 package to the ROS build farm using bloom. Be sure to check the first and second parts if you haven’t yet:
Before anything else, if you want to use the logo above on your own robot or computer, feel free to download it and attach it to your robot. It is really free. Find it in the link below:
In order to follow this tutorial, we need to have ROS2 installed in our system, and ideally a ros2_ws (ROS2 Workspace). To make your life easier, we have already prepared a rosject with a simulation for that: https://app.theconstructsim.com/l/5562c7f1/.
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).
How to release a ROS 2 binary package – Part 3 – Run rosject (example of the RUN button)
After pressing the Run button, you should have the rosject loaded. Now, let’s head to the next section to get some real practice.
What is bloom?
Bloom is a build automation tool that will guide you through all necessary steps in the process of compiling the source code in the ROS build farms, packaging the code into binaries, and uploading them to the Debian archive. This way any users can easily install and uninstall it using the Debian package tools.
What is a build farm?
A build farm is a collection of one or more servers, which has been set up to compile computer programs remotely.
Assumptions
In order to follow this tutorial, we assume you have:
An existing ROS2 Package, publicly available for everyone to use
Recap from part 1: Install the tools required on your machine
After having opened the rosject, let’s start running some commands in the terminal. For that, let’s open a terminal by clicking the Open a new terminal button.
Open a new Terminal
Once inside the terminal, let’s run the commands below, use apt to install bloom together with the python3-catkin-pkg modules if you haven’t done so already.
sudo apt update
sudo apt install python3-bloom python3-catkin-pkg
New addition step: Since we are using a version of bloom older than 0.6.8 we need to use the v4 index URL for releasing:
If you followed the second part of this video, you created a pull request to add a ros/rosdistro source entry. Remember that you have to make the changes requested by the reviewer to get your pull request merged. This part assumes that your pull request has been successfully merged to the ros/rosdistro repository.
Important: The issues created in part 1 and part 2 must be shown as completed.
Verify your repository is up to date and your code builds
This might seem like an obvious one, but it’s easy to overlook. Ensure you have committed your changes and pushed the last commit to your remote.
Additionally, confirm your new code builds and executes right before making it available to the build farm.
cd ~/ros2_ws/src
git clone https://github.com/rfzeg/wall_follower_ros2
cd ~/ros2_ws
colcon build; source install/setup.bash
IMPORTANT!!!
Here we cloned the https://github.com/rfzeg/wall_follower_ros2 package. You cannot release the same package from the same URL because it has been already released by ROS, which means some parts of this tutorial may not work 100% if you close the same repository.
To make sure it works, you have to close your own repository instead of the one above. Please use the same repository you used in the previous posts of this series, for example.
Starting the simulation
After having opened the rosject and making sure the workspace builds with no problems, let’s start a simulation using the same terminal that you have already opened previously.
Let’s run the following commands in order to launch the simulation:
Now, in a second terminal, let’s make sure our wall follower is working properly:
ros2 run wall_follower_ros2 wall_follower_ros2 --ros-args -r scan:=/lidar_1/out
If everything went well, you should see the robot moving around, and when it gets close to the wall, it turns and keep moving:
Wall follower using ROS 2
It is always a good idea to verify if there are new changes since the last commit. Let’s try that in the same second terminal. For that, first press CTRL+C to kill the current process, and then run the commands below:
cd ~/ros2_ws/src/wall_follower_ros2
git status
When you have added all of the changes to a commit, the Git status command line will inform you ‘nothing to commit, working tree clean‘ :
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Generating the Changelog
We are now going to generate a Changelog. A changelog is a file that contains a condensed list of all important changes made to a project in a chronologically ordered way. Its purpose is to communicate to other developers what features have been added, improved, or removed over time.
To auto-generate the CHANGELOG.rst files, use the "catkin_generate_changelog --all" command.
Make sure to run this command from inside the home directory where the package files are located:
cd ~/ros2_ws/src/wall_follower_ros2
catkin_generate_changelog --all
If everything went well, we expect to have the following output:
Found packages: wall_follower_ros2
Querying all tags and commit information...
Generating changelog files with all versions...
- creating './CHANGELOG.rst'
Done.
Please review the extracted commit messages and consolidate the changelog entries before committing the files!
A new CHANGELOG.rst file will be automatically created for every package within the repository. The above command will also populate the file with the contents of your commit messages.
The above command will generate a CHANGELOG.rst file. If we open that file using the Code Editor, or by typing “cat CHANGELOG.rst“, we should see something similar to the following, for instance:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Changelog for package wall_follower_ros2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Forthcoming
-----------
* Merge pull request `#1 <https://github.com/rfzeg/wall_follower_ros2/issues/1>`_ from rfzeg/master
Master to main
* Feat: stop robot when a CTRL+C signal is received
* Fix safety_distance parameter value
* Add parameter to reverse ranges array in case it starts with rays at the left side
* Refactor: rename, reformat and rearrange code
* Add Timer Callback to set movement state, fill vel msg, publish vel msg
* Refactor laser_callback to get the distance reading to the closest object and the ray's position index
* Rename set_drive_state() -> set_drive_logic_state(), RCLCPP_INFO() -> RCLCPP_DEBUG() logs
* Rename set_velocity() -> determine_vel_msg(), rewrite debug logs
* Rename package to 'wall_follower_ros2'. Set version to 0.0.0 in package.xml
* Add info & debug log messages
* Add logical behavoir depending upon 5 zones around the robot, set velocity command
* Add log info & debug statements
* Refactor parameter value retrieval
* Add safety distance parameter
* Add default parameter values
* Add minimal rule based obstacle avoidance node (c++)
* Add initial ROS2 package files, Readme, License & Git configuration
* Contributors: Roberto Zegers, Roberto Zegers R
Note: The changelog is basically a list of commits. I you want to compare it with your log messages, have a look at the Git log history using git log –oneline:
git log --oneline
So, the changelog is basically a list of commits, but you can definitely remove some of the commits in the changelog if you want, however, you must not remove the Forthcoming header.
AGAIN!!! Make sure you do not modify the Forthcoming header.
In this example I reduced the list of changes to only include the most important things as shown below:
Forthcoming
-----------
* Add initial version with logical behavoir depending upon 5 zones around the robot
* Contributors: Roberto Zegers
If you have modified the changelog, then you must commit CHANGELOG.rst changes giving it an appropriate commit message such as “Add Changelog”.
git add CHANGELOG.rst
git commit -m "Add Changelog"
Bump the package version
Before releasing the package you will also have to increment its version number to a new, unique value because by default its initial version will be “0.0.0″, which is the value defined in the package.xml file of our package.
To confirm that number, you can run the command below:
cat ~/ros2_ws/src/wall_follower_ros2/package.xml | grep version
which will output something like this:
<version>0.0.0</version>
Now, in order to automatically bump the package version, we can use the following command, but be aware that the command will ask you for your github credentials. That is why we mentioned previously that you would have to clone your own repository instead of the one we are using in this example (https://github.com/rfzeg/wall_follower_ros2):
cd ~/ros2_ws/src/wall_follower_ros2
catkin_prepare_release
According to the ROS2’s documentation, this command performs the following:
Increases the package version in package.xml. The above command will increment the patch version of the package from its default value of 0.0.0 to 0.0.1.
Replaces the heading Forthcoming with version (date) (eg. 0.0.1 (2022-01-08)) in CHANGELOG.rst
Commits those changes
Creates a Git tag (eg. 0.0.1) to mark this point in the Git history
Pushes the changes and the tag to your remote repository
You can show the changes made to the repository like this:
git diff HEAD^ HEAD
If you want to verify the tag that Git just added, run the command below, which will list the available tags in your Git repository:
git tag
Sidenote on semantic versioning
A semantic version number has three parts delimited by a dot, for instance:
1.2.5
Where 1 stands for a Major version, 2 represents the Minor version and 5 is the Patch. Let’s understand these labels:
Patch: Patch updates are interchangeable, meaning consumers can upgrade or downgrade freely. Example: Bug fix, performance improvement, or internal tweaks.
Minor: Minor updates are backward compatible, meaning consumers can upgrade freely. For instance new additional API methods, without changing the current methods.
Major: Major updates are non-compatible, meaning consumers can not upgrade without changing the software that uses the API, where applicable. You normally have interface changes breaking backward compatibility, like changes in an API endpoint name or signature, removal of an endpoint, etc.
To increment the major version, for instance in the first major release, run:
catkin_prepare_release --bump major
Similarly, the minor version gets incremented when you execute:
catkin_prepare_release --bump minor
Run the bloom-release command
Run the following command, the <my_repository> should be replaced with the name of your repository:
The above command will create a release for ROS2 Humble. Let’s have a quick breakdown of the flags we used:
–new-track is important for a first-time release to create a new track before running bloom. What is a track? Bloom is designed to allow the release of the same package for different ROS distributions and versions in the same release repository. To facilitate this, bloom uses release “tracks” to maintain configurations for different release processes.
–rosdistro humble indicates that this release is for the humble distro. Replace as appropriate.
–track humble indicates that you want the track name to be humble
Note: For later releases, you don’t need the --new-track flag. However, if you want to add a new distribution to an already released package (see documentation) and configure it, you will have to include the --new-track option again.
Once executed, it will look at the distributions.yaml file for your project key. If it doesn’t find it, it’ll look in other distributions. If it finds one, it’ll prompt you to approve it. If not, you will be asked to enter a release repository URL:
Looking for a release of this repository in a different distribution
In this particular example, we have to add the following. Note that you should replace this with the name of your repository.
AGAIN!!! Note that you should replace this with the name of your repository.
Note: The release process begins recording logs as soon as you run it. Bloom log files are saved in your local machine to this directory: '/home/user/.bloom_logs'
The pull request page
Click on that link and you will see the current status of your pull request:
ROS ROSDISTRO Pull Request on GitHub
Now you will have to wait for someone from the ROS release team to review/merge the pull request.
This can take some time, so you may have to wait a bit.
If required you will have to update the PR to address the comments. That is all for today’s post.
Congratulations. You just learned the third part of how to publish your ROS 2 binary package.
We hope this post was really helpful to you. If you want a live version of this post with more details, 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:
ROS2 parameters are great for configurable nodes that you can adapt to your robot configuration simply by changing a configuration file or a launch file. However, if we just implemented the basics you will have to re-run your node each time you change a parameter. You can’t change the parameter on-the-fly and have it updated in the robot. But by adding a callback function that updates the variables in our code, it is possible to do a live parameter update while a program is running, removing the need for a tedious node restart. Learn how to do it in this post.
ROS Inside!
ROS Inside
Before anything else, if you want to use the logo above on your own robot or computer, feel free to download it and attach it to your robot. It is really free. Find it in the link below:
In order to follow this tutorial, we need to have ROS2 installed in our system, and ideally a ros2_ws (ROS2 Workspace). To make your life easier, we have already prepared a rosject with a simulation for that: https://app.theconstructsim.com/l/53e75e28/.
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 how to enable live parameter updates (C++) – Run rosject (example of the RUN button)
After pressing the Run button, you should have the rosject loaded. Now, let’s head to the next section to get some real practice.
Starting the simulation
After having opened the rosject, let’s start a simulation. For that, let’s open a terminal by clicking the Open a new terminal button.
Open a new Terminal
Once inside the terminal, let’s run the commands below:
If everything went well, you should have a simulation loaded and opened automatically in a few seconds. The simulation will open from a top view, but you can use the mouse to move the simulation to a different perspective.
How to enable live parameter updates (C++)
Understanding the problem
Below is an example node in which we have only implemented the barebone basics of parameters in ROS2.
Let’s see it in action and see how it behaves, especially when we update its parameter values.
In a second terminal, let’s run the node for Obstacle Avoidance.
source ~/ros2_ws/install/setup.bash
ros2 run rule_based_obstacle_avoidance obstacle_avoidance
If you watch the simulation for a while, you will see that when the robot detects the wall, it rotates and moves forward until it detects another wall, and repeats the process.
The node name is obstacle_avoidance_node (you can check it in a third terminal by running: ros2 node list)
Now, let’s list the parameters of the node in a third terminal:
Now, still in the third terminal, let’s check the value of the safety_distance parameter:
ros2 param get /obstacle_avoidance_node safety_distance
The output we should have got should be the following:
Double value is: 1.5
Now, let’s set the parameter to a new value:
ros2 param set /obstacle_avoidance_node safety_distance 1.0
The expected output is:
Set parameter successful
Ok, so far so good. But with the new value, we expect the robot to get closer to the wall before turning around because now the safe distance was set from 1.5 meters to 1.0. The problem is that the robot is not considering the new value that we just set.
We can follow the same idea to try to make the robot move faster. Let’s check the current velocity of the robot:
ros2 param get /obstacle_avoidance_node linear_x_velocity
The output we should have got should be the following:
Double value is: 0.2
If we increase the speed:
ros2 param set /obstacle_avoidance_node linear_x_velocity 0.5
The expected output is:
Set parameter successful
The parameter was reported as successfully set, yet the robot does not move faster, because it still uses the value loaded when the node started.
In the current code, parameter values are fixed. As such, every time a parameter value changes, the parameter value in the code stays the same even though you may have expected it to update based on the latest value set.
In order to solve this, we must add a parameter callback function to your code so that the variable in the code gets the freshest data.
Before moving to the next section, please kill the simulation and all nodes running by pressing Ctrl+C on all terminals.
Solution: Add a parameter callback method
Alright, have you closed all programs by pressing CTRL+C on all terminals?
If you check around line 45 on that file, you will find the “private:” section, where we define the private variables of our class, something like the following:
Now, above that “private:” section, around line 38, let’s add the following code to instantiate a ParameterEventHandler, providing the current ROS node to use to create the required subscriptions:
Below the param_subscriber_ we have to set a callback method, in this case, a lambda function:
// Set a callback for this node's parameter, "linear_x_velocity"
auto callback_linear_x = [this](const rclcpp::Parameter &p) {
RCLCPP_INFO(this->get_logger(),
"callback_linear_x: Received an update to parameter \"%s\" "
"of type %s: \"%f\"",
p.get_name().c_str(), p.get_type_name().c_str(),
p.as_double());
linear_x_velocity_ = p.as_double();
};
Then we set “callback_linear_x” as the callback to invoke whenever linear_x_velocity is updated. We store the handle that is returned by “add_parameter_callback“; otherwise, the callback will not be properly registered.
Now that our package has been rebuilt and sourced, let’s launch the simulation again:
ros2 launch neo_simulation2 simulation.launch.py
The simulation should have been opened just like before, but now we will see the parameters affecting the simulation in “real-time”.
Before changing the parameters, let’s also launch the Obstacle Avoidance node, just like before, using the second terminal:
ros2 run rule_based_obstacle_avoidance obstacle_avoidance
You should see the robot approaching the wall, and turning around when getting close to it.
Changing the x velocity using ROS 2 Parameters
Ok, now that the robot is moving, let’s retrieve again the current value of the linear x velocity using the third terminal:
ros2 param get /obstacle_avoidance_node linear_x_velocity
Just like before, the expected output is:
Double value is: 0.2
Now let’s change that value:
ros2 param set /obstacle_avoidance_node linear_x_velocity 1.0
We expect a successful output:
Set parameter successful
If you look at the simulation now, you should see that when the robot is moving forward (not turning around), it moves really faster. So, as we can see, we are now able to make ROS2 Parameters be reflected “instantly”.
This opens up really many different possibilities.
We hope this post was really helpful to you. If you want a live version of this post with more details, 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:
Before we start really using ROS2 parameters, let’s understand key points about them:
Parameters in ROS2 are implemented/attached to/served by each node individually, as opposed to the parameter server associated with roscore in ROS1, therefore, when the node dies, so do its parameters. This is easier to understand if you already know that in ROS2 we do not have roscore.
Parameters can be loaded at the node startup or while the node is running
Having this in mind, our life now understanding ROS2 params is going to become easier.
Opening the rosject
In order to learn how to load and retrieve ROS2 Parameters, we need to have ROS installed in our system, and it is also useful to have some simulations. We already prepared a rosject with a simulation for that: https://app.theconstructsim.com/#/l/4875b2e0/.
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.
Learn ROS2 Parameters – Run rosject
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 turtlebot simulation with ROS2
In order to launch the simulation, let’s start by opening a new terminal:
Open a new Terminal
After having the first terminal open, let’s run the following commands to launch a simulation:
Wait some seconds until the simulation is loaded. If for any reason the simulation does not load and you see error messages like the following:
[INFO] [1649093592.180346898] [spawn_entity]: Waiting for service /spawn_entity
[ERROR] [1649093597.566604708] [spawn_entity]: Service %s/spawn_entity unavailable. Was Gazebo started with GazeboRosFactory?
[ERROR] [1649093597.567565097] [spawn_entity]: Spawn service failed. Exiting.
[ERROR] [spawn_entity.py-4]: process has died [pid 1007, exit code 1, cmd '/opt/ros/galactic/lib/gazebo_ros/spawn_entity.py -entity waffle_pi -file /home/user/simulation_ws/install/turtlebot3_gazebo/share/turtlebot3_gazebo/models/turtlebot3_waffle_pi/model.sdf -x 0.0 -y 0.0 -z 0.01 --ros-args']
you can just abort the current command by pressing CTRL+C in the terminal, then run the last command “ros2 launch turtlebot3_gazebo empty_world.launch.py” again.
If everything loaded fine, you should have a Turtlebot Waffle PI simulation running:
Turtlebot Waffle PI – How to use ROS2 parameters
Checking ROS2 Topics to ensure the simulation is ok
Now that our simulation is running, we can check the topics just to make sure everything loaded as expected.
For that, let’s open a second terminal and type the following command:
ros2 topic list
If you see the following list of topics, then everything has loaded fine:
If you look carefully in the list of topics, we have the topic /cmd_vel. We are going to use it to send velocity commands to the robot using ROS parameters.
Understanding the parameter_tests package
So far so good. It is now time to check the structure of our workspace. Let’s start by opening our Code Editor:
Open the IDE – Code Editor
After having the IDE open, under ros2_ws/src you should find a package named parameter_tests.
Inside that package, there is also a folder named parameter_tests with a file named parameter_tests_node.py. Please click on that file to open it and analyze its code.
The code is the following:
import rclpy
import rclpy.node
from rcl_interfaces.msg import ParameterDescriptor
from geometry_msgs.msg import Twist
class VelParam(rclpy.node.Node):
def __init__(self):
super().__init__('param_vel_node')
self.timer = self.create_timer(0.1, self.timer_callback)
self.publisher = self.create_publisher(Twist, 'cmd_vel', 10)
self.msg = Twist()
param_descriptor = ParameterDescriptor(
description='Sets the velocity (in m/s) of the robot.')
self.declare_parameter('velocity', 0.0, param_descriptor)
# self.add_on_set_parameters_callback(self.parameter_callback)
def timer_callback(self):
my_param = self.get_parameter('velocity').value
self.get_logger().info('Velocity parameter is: %f' % my_param)
self.msg.linear.x = my_param
self.publisher.publish(self.msg)
def main():
rclpy.init()
node = VelParam()
rclpy.spin(node)
if __name__ == '__main__':
main()
If you check the main function, we are basically starting the ROS node, instantiating an object of our VelParam class, and spinning that node.
On the VelParam, one of the most important parts is where we define the param_descriptor. That param descriptor is what we use to set a parameter called velocity and define its initial value as 0.0.
Every certain amount of time (0.1 sec) the timer_callback method is called.
If we now check that timer_callback method, we see that it basically reads the velocity parameter and uses it to publish a velocity to the /cmd_vel.
Running the parameter_tests_node node
Now that we understand what our node does, it is time to run it.
For that, let’s open a third terminal and run the following command:
ros2 run parameter_tests param_vel
You should see constant messages like the following:
[INFO] [1649095105.555241669] [param_vel_node]: Velocity parameter is: 0.000000
[INFO] [1649095105.559028822] [param_vel_node]: Velocity parameter is: 0.000000
[INFO] [1649095105.583306104] [param_vel_node]: Velocity parameter is: 0.000000
...
We see that the initial value of the velocity parameter is 0 (zero).
Checking ROS Parameters using the terminal
Ok, so far we see everything is working, and we were are able to set and retrieve the ROS Param using Python.
Now let’s list the parameters to identify our velocity param. Let’s open a third terminal and type ros2 param list. The output should be similar to the following:
The node we are interested in is the param_vel_node. In the output above, we can easily identify our velocity param there:
user:~$ ros2 param list
/param_vel_node:
use_sim_time
velocity
the use_sim_time is a parameter that comes in every node.
Moving the robot using ROS Parameter
That that we have the param_vel_node with the velocity param, we can easily set a value to that parameter with the following command:
ros2 param set /param_vel_node velocity 0.2
After running this command, you should see that the robot started moving.
If you also check the terminal where we launched our node, it should say the current value or our parameter:
[INFO] [1649096658.093696410] [param_vel_node]: Velocity parameter is: 0.200000
[INFO] [1649096658.181101399] [param_vel_node]: Velocity parameter is: 0.200000
[INFO] [1649096658.281628131] [param_vel_node]: Velocity parameter is: 0.200000
Remember that you can easily set the parameter to 0.0 again to stop the robot:
ros2 param set /param_vel_node velocity 0.0
Dumping ROS Parameters into a YAML file (YAML format)
Now that we saw that we can easily move the robot back and forth using ROS parameters, in case you need to somehow dump the parameters, you can easily do it with:
cd ~/ros2_ws/src/parameter_tests/config
ros2 param dump /param_vel_node
The command will generate a file named ./param_vel_node.yaml with the following content (after we have set the velocity to 0.0 again):
Loading ROS Parameters when running Node using YAML files
All right, so far we have learned how to set parameters using Python and using the command line directly through ros2 param set. Now the time has come to also learn how to launch a node and set the parameters from a YAML file.
Before we do that, feel free to change the velocity value in the param_vel_node.yaml file.
Please, go to the second terminal where you launched the node and press CTRL+C to kill it. The simulation should be kept running.
Now, launch the node again, but now loading the parameters from the YAML file using the following command:
ros2 run parameter_tests param_vel --ros-args --params-file /home/user/ros2_ws/src/parameter_tests/config/param_vel_node.yaml
Based on the logs that are printed on the screen, you should be able to see that the parameters were correctly loaded from the YAML file.
Loading ROS Parameters using launch files directly
Up to now, we were launching our node using ros2 run, but if you are familiar with ROS, you may know that we can also use ros2 launch to launch ROS2 nodes.
If you check carefully the rosject, you will find a launch file under the following path:
Congratulations, you now know all the basics about ROS Parameters in 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.
Keep pushing your ROS Learning.
Related Courses & Training
If you want to learn more about ROS and ROS2, we recommend the following courses:
If you are interested in robotics, you must have heard of ROS (Robot Operating System). ROS is now very popular among roboticists. Researchers, hobbyists, and even robotics companies are using it, promoting it. and supporting it. But what is ROS? How did ROS reach its current state as a robotics standard? Why is ROS becoming a must-have skill for robotics practitioners? In this article, we will reveal the answers to these questions.
Keep on reading to understand ROS, or jump ahead to the section that interests you most.
Before we understand what ROS is, let me introduce you to ROS with a short history of how it started, the main reasons behind it, and its current status.
The Stanford Period
Similar frameworks at the time
Switching gears
Willow Garage takes the lead
Under the Open Source Robotics Foundation umbrella
ROS 2.0
Recent movements in the ROS ecosystem
The Stanford Period
ROS started as a personal project of Keenan Wyrobek and Eric Berger while at Stanford, as an attempt to remove the reinventing-the-wheel situation from which robotics was suffering. These two guys were worried about the most common problem of robotics at the time:
too much time dedicated to re-implementing the software infrastructure required to build complex robotics algorithms (basically, drivers to the sensors and actuators, and communications between different programs inside the same robot)
too little time dedicated to actually building intelligent robotics programs that were based on that infrastructure.
Even inside the same organization, the re-invention of the drivers and communication systems was re-implemented for each new project. This situation was beautifully expressed by Keenan and Eric in one of their slides used to pitch investors.
Most of the time spent in robotics was reinventing the wheel (slide from Eric and Keenan pitch deck)
In order to attack that problem, Eric and Keenan created a program at Stanford called the Stanford Personal Robotics Program in 2006, with the aim to build a framework that allowed processes to communicate with each other, plus some tools to help create code on top of that. All that framework was supposed to be used to create code for a robot they would also build, the Personal Robot, as a test bed and example to others. They would build 10 of those robots and provide them to universities so that they could develop software based on their framework.
NOTE: People more versed in ROS will recognize the precursors of ROS-comm libraries and the Rviz, rqt_tools and the like of current modern ROS distributions. Also, the Personal Robot was the precursor to the famous PR2 robot.
PR1 robot, picture by IEEE Spectrum
Similar frameworks at the time
The idea of such a system for robotics was not new. Actually, there were some other related projects already available for the robotics community: Player/Stage, one of the most famous in the line of open source, and URBI in the line of proprietary systems. Even Open-R, the system developed by Sony, which powered the early Aibo robots of 1999, was a system created to prevent that problem (a shame that Sony cancelled that project, as they could have become the leaders by now. Ironically, this year, Sony launched a new version of the Aibo robot… which runs ROS inside!). Finally, another similar system developed in Europe was YARP.
Actually, one of the leaders of the Player/Stage research project was Brian Gerkey, who later went to Willow Garage to develop ROS, and is now the CEO of Open Robotics, the company behind the development of ROS at present. On its side, URBI was a professional system led by Jean-Christoph Baillie, which worked very well, but could not compete with ROS, which was free.
The fastest readers will jump to the point that URBI was not free. Actually, it was quite expensive. Was the price what killed URBI? I don’t think so. In my opinion, what killed URBI was the lack of community. It takes some time to build a community, but once you have it, it acts like changing gears. URBI could not build a community because it relied on an (expensive) paid fee. That made it so that only people that could buy it were accessing the framework. That limits the amount of community you can create. It is true that ROS was free. But that is not the reason (many products that are free fail). The reason is that they built a community. Being free was just a strategy to build that community.
Switching gears
While at Stanford, Keenan and Eric received $50k of funding and used it to build a PR robot and a demo of what their actual project was. However, they realized that in order to build a really universal system and to provide those robots to the research groups, they would need additional funding. So they started to pitch investors.
At some point around 2008, Keenan and Eric met with Scott Hassan, investor and the founder of Willow Garage, a research center with a focus on robotics products. Scott found their idea so interesting that he decided to fund it and start a Personal Robotics Program inside Willow Garage with them. The Robot Operating System was born, and the PR2 robot with it. Actually, the ROS project became so important that all the other projects of Willow Garage were discarded and Willow Garage concentrated only on the development and spread of ROS.
Willow Garage takes the lead
ROS was developed at Willow Garage over the course of 6 years, until Willow shut down, back in 2014. During that time, many advancements in the project were made. It was this push during the Willow time that skyrocketed its popularity. It was also during that time that I acknowledged its existence (I started with ROS C-turtle in 2010) and decided to switch from Player/Stage (the framework I was using at that time) to ROS, even if I was in love with Player/Stage (I don’t miss you because ROS is so much better in all aspects… sorry, Player/Stage, it’s not me, it’s you).
In 2009, the first distribution of ROS was released: ROS Mango Tango, also called ROS 0.4. As you can see, the name of the first release had nothing to do with the current naming convention (for unknown reasons to this author). The release 1.0 of that distribution was launched almost a year later in 2010. From that point, the ROS team decided to name the distributions after turtle types. Hence, the following distributions and release dates were done:
In 2009, they built a second version of the Personal Robot, the PR2
In xxx, they launched ROS Answers, the channel to answer technical questions about ROS.
The first edition of the ROSCON was in 2012. The ROSCON became the official yearly conference for ROS developers.
In 2010, they built 11 PR2 robots and provided them to 11 universities for robotics software development using ROS (the original idea of Eric and Keenan). At that point, the PR2 robot was for sale, so anybody in the world could buy one (if enough money was available ;-)).
Simulation started to become very important. More precisely, 3D simulation. That is why the team decided to incorporate Gazebo, the 3D robotics simulator from the Player/Stage project, into ROS. Gazebo became the default 3D simulator for ROS.
As ROS was evolving, all the metrics of ROS were skyrocketing. The number of repositories, the number of packages provided, and of course, the number of universities using it and of companies putting it into their products.
Evolution of ROS in the early days (picture from Willow Garage)
Another important event that increased the size of the ROS community was when, in 2011, Willow Garage announced the release of the Turtlebot robot, the most famous robot for ROS developers. Even if PR2 was the intended robot for testing and developing with ROS, its complexity and high price made it non-viable for most researchers. Instead, the Turtlebot was a simple and cheap robot that allowed anybody to experiment with the basics of robotics and ROS. It quickly became a big hit, and is used even today, in its Turtlebot2 and Turtlebot 3 versions.
I remember when we received the news that Willow Garage was closing. I was working at Pal Robotics at the time. We at Pal Robotics were all very worried. What would happen with ROS? After all, we had changed a lot of our code to be working with ROS. We removed previous libraries like Karto for navigation (Karto is software for robot navigation, which at present is free, but at that time, we had to pay for a license to use it as the main SLAM and path planning algorithms of our robots).
The idea was that the newly created Open Source Robotics Foundation would take the lead in ROS development. And many of the employees were absorbed by Suitable Technologies (one of the spin-offs created from Willow Garage, which ironically does not use ROS for their products ;-)). The customer support for all the PR2 robots was absorbed by another important company, Clearpath Robotics.
Under the Open Source Robotics Foundation umbrella
Under the new legal structure of the OSRF, ROS continued to develop and release new distributions.
The reports created after each year are publicly available here under the tag ROS Metrics.
Having reached this point, it is important to state that the last distribution of ROS will be released in 2020. It is called ROS Noetic, which will be based on Python 3, instead of Python 2 as all the previous ones were. From that date, no more ROS 1 distributions will be released, and the full development will be taken for ROS 2.
Around 2015, the deficiencies of ROS for commercial products were manifesting very clearly. Single point of failure (the roscore), lack of security, and no real-time support were some of the main deficiencies that companies argued for not supporting ROS in their products. However, it was clear that, if ROS had to become the standard for robotics, it had to reach the industrial sector with a stronger voice than that of the few pioneer companies already shipping ROS in their products.
In order to overcome that point, the OSRF took the effort to create ROS 2.0.
ROS 2.0 had already reached its fourth distribution in June 2019 with the release of Dashing Diademata.
Recent movements in the ROS ecosystem
In 2017, the Open Source Robotics Foundation changed its name to Open Robotics, in order to become more of a company than a foundation, even if the foundation branch still exists (some explanation about it can be found in this post and in this interview with Tully Foote).
Recently, Open Robotics has opened a new facility in Singapore and established a collaboration with the government there for development.
Local ROS conferences have been launched:
ROSCON France
ROSCON Japan
In the last few months, big players like Amazon, Google, and Microsoft have started to show interest in the system, and show support for ROS.
That is definitely a sign that ROS is in good health (I would say in better than ever) and that it has a bright future in front of it. Sure, many problems will arise (like, for example, the current problem of creating a last ROS 1 distribution based on Python 3), but I’m 100% sure that we, and by we I mean the whole ROS community, will solve them and build on them.
What is ROS?
Why are there not enough developers for robotics?
Roboticists programming robots
What is the robot ROS API?
What is ROS anyway?
ROS for service robots
ROS for industrial robots
ROS for agricultural robots
A story of software & hardware: why are there not enough developers for robotics?
In general, software developers do not like to deal with hardware. It is very likely that you are a software developer and never thought about entering into the robotics field. You probably think that by programming for robots, you would have to know about electronics, and maybe even mechanics. You probably think that hardware and software are too coupled in robots, that you cannot touch one without touching the other. And sometimes, it is true…
About 10 years ago, we had to develop a navigation system for a robot. However, our navigation program was not working at all. We thought that it was something wrong with the program, but after extensive review and testing in simulations, we found that it actually was a problem with the electronics of the laser scanner that we used to localize the robot. In order to find that error, we had to go to the basics and find where the problem within the physical laser was. For that, we needed to mess with the electronics. We had to take the laser out of the robot, put it on the table, and start experimenting. Different voltages, different interruptions to the power, all in order to try to reproduce the effect in a controlled environment. That is a lot of interaction with the hardware.
That interaction with the hardware is something that many software developers don’t like. After all, they decided to become software developers, not hardware developers!!
Roboticists programming robots
Due to this, the programming of robots has been done by roboticists, who are the people that build the robots. Maybe some of the roboticists were not directly involved in the creation of the robot, but they definitely have no problem getting into the hardware and trying to fix hardware problems in order to make their programs work.
But let’s face it, most roboticists are not as good at programming as software developers are. That is why robotics could benefit so much from having lots of expert programmers coming to the field.
The good news is that getting developers into the field is easier than ever. Thanks to the Robot Operating System, ROS, you can completely abstract the hardware from the software, so you can program a robot just by knowing the robot’s ROS API and having a simulation for testing. By using the ROS API, you can forget about the hardware and just concentrate on the software that makes the robot do what you want.
What is the robot ROS API?
The ROS API is the list of ROS topics, services, action servers, and messages that a given robot is providing to give access to its hardware, that is, sensors and actuators. If you are not familiar with ROS, you may not understand what those terms mean. But simply put in the developers’ language, topics/services/messages are like the software functions you can call on a robot to get data from the sensors or make the robot take action. It also includes the parameters you can pass on to those functions.
Most modern robot builders are providing off-the-shelf ROS APIs, for example, the ROS-Components shop that provides all its hardware running with a ROS API.
If the robot you want to work with does not run ROS, you can still make the robot work with ROS by ROSifying it. To ROSify means to adapt your robot to work with ROS. ROSifying a robot usually requires knowledge to access the hardware. You need to learn how to communicate with the electronics that provide the sensor data or access the motors of the robot. In this series of ROS tutorials, we are not dealing with that subject because it gets out of scope for developers. But if you are interested in this topic, you can learn more about it in this Robot Creation Course.
What is ROS anyway?
ROS stands for Robot Operating System. Even if the name says so, ROS is not a real operating system since it goes on top of Linux Ubuntu (also on top of Mac, and recently, on top of Windows). ROS is a framework on top of the O.S. that allows it to abstract the hardware from the software. This means, you can think in terms of software for
all the hardware of the robot. And that is good news for you because this implies that you can actually create programs for robots without having to deal with the hardware. Yea!
ROS works on Linux Ubuntu or Linux Debian. Experimental support already exists for OSX, Gentoo, and a version for Windows is under way, but we really don’t recommend for you to use them yet unless you are an expert. Check this page for more information about how to use ROS on those systems.
ROS for service robots
ROS is becoming the standard in robotics programming, at least in the service robots sector. Initially, ROS started at universities, but quickly spread into the business world. Every day, more and more companies and startups are basing their businesses on ROS. Before ROS, every robot had to be programmed using the manufacturer’s own API. This means that if you changed robots, you had to start the entire software again, apart from having to learn the new API. Furthermore, you had to know a lot about how to interact with the electronics of the robot in order to understand how your program was doing. The situation was similar to that of computers in the 80s, when every computer had its own operating system and you had to create the same program for every type of computer. ROS is for robots like Windows is for PCs, or Android for phones. By having a ROSified robot, that is, a robot that runs on ROS, you can create programs that can be shared among different robots. You can build a navigation program, that is a program to make a robot move around without colliding, for a four-wheeled robot built by company A and then use the same exact code to move a two-wheeled robot built by company B… or even use it on a drone from company C, with minor modifications.
ROS for industrial robots
ROS is being used in many of the service robots that are created at present. On the other side, industrial robotics companies are still not completely convinced about using it, mainly because they will lose the power of having a proprietary system. However, four years ago, an international group called ROS-Industrial (https://rosindustrial.org/) was created, whose aim is to make industrial manufacturers of robots understand that ROS is for them, since they will be able to use all the software off-the-shelf that other people have created for other ROS robots.
ROS for agricultural robots
In the same vein as ROS-Industrial, ROS-Agriculture (http://rosagriculture.org/) is another international group that aims to introduce ROS for agriculture robots. I highly recommend that you follow this group if you are interested because they are a very motivated team that can do crazy things with several tons of machine, by using ROS. Check out, for instance, this video (https://youtu.be/obu_Ru2gDHk) about an autonomous tractor running ROS, built by Kyler Laird of the ROS Agriculture group.
Why ROS?
The question then is this: why has ROS emerged on top of all the other possible contestants? None of them is worse than ROS in terms of features. Actually, you can find some features in all the other middlewares that outperform ROS. If that is so, why or how has ROS achieved the status of becoming the standard?
A simple answer from my point of view: excellent learning tutorials and debugging tools.
Here is a video where Leila Takayama, early developer of ROS, explains when she realized that the key for ROS to be used worldwide would be to provide tools that simplify the reuse of ROS code. None of the other projects have such a set of clear and structured tutorials. Even less, those other middlewares provide debugging tools in their packages. Lacking those two essential points is preventing new people from using their middlewares (even if I understand why the developers of OROCOS and YARP for not providing it… who wants to write tutorials or build debugging tools… nobody! 😉 )
Additionally, it is not only about Tutorials and Debugging-Tools. ROS creators also managed to create a good system of managing packages. The result of that is that developers worldwide could use others’ packages (relatively) easily. This created an explosion in available ROS packages, providing almost anything off-the-shelf for your brand-new ROSified robot.
Now, the rate at which contributions to the ROS ecosystem are made is so fast that it makes ROS almost unstoppable in terms of growth. According to ABI Research, about 55% of the world’s robots will include a ROS package by 2024. This is an indication of the fact that in ten years, ROS has become a defacto robotics standard, in academia and increasingly in industry. More and more universities are teaching robotics with ROS. The ROS Curriculum For Campus project that we launched in 2018 has been used by hundreds of universities. It is easy to see why ROS has become a must-have skill in the CV of robotics practitioners.
How to start learning ROS
Now, if you are convinced about becoming a ROS developer 😉 then using this beginner’s guide, we can follow these five steps to successfully learn ROS:
In order to create ROS programs, you will need a C++ or Python code editor. In this chapter, we are going to show you a list of integrated environments for programming ROS with those languages.
Hello ROS developers! In this post, we’ll find out what happened to roscore in ROS2 and how similar functions of the ROS1 master were implemented in ROS2. Sit back and get ready to have some fun!
In order to approach this theory-like topic with as much practical as possible, this post has two main sections:
Some tinkering with a ROS2 installation. This is the real fun part: trying to find roscore in ROS2.
Some theory. As this might be a little boring, so we’ll keep it short and sweet!
Section 1: Trying to find roscore in a ROS2 installation
Since ROS2 arrived in town, there has been a rumour going round that “roscore is missing”! But don’t take anyone’s word for it; let’s find out for ourselves. Shall we?
We need a functional ROS2 installation for this. We will use one of the awesome Docker images of ROS2 provided by the Open Source Robotics Foundation (OSRF), to keep it easy for everyone and make sure we can tinker with ROS2 without committing too much time to installing it (yet). Choose any of the following options:
Spin a free ROS development environment at ROSDS. With this, you skip all installations; just a few clicks and you will have access a ROS-ready computer within your browser. This is the recommended option.
You have docker installed on your local development machine. Please note that a ROS2 installation is not necessary since we’re using a docker image, but if you have ROS2 installed already you may choose to use it instead of the docker image.
We are using option 1 for this post. It’s about time we skipped local installations and start developing within our browsers, but I digress.
Now is time for action: fire up a terminal on your machine and get ready to shoot some commands at it! Our first task is spinning up the ROS2 docker installation:
user:~$ docker run -it osrf/ros2:bouncy-ros-core
Unable to find image 'osrf/ros2:bouncy-ros-core' locally
...
root@d213f10c91f9:/#
You should get something like the above, ending with a prompt that grants access to the ROS2 docker machine. Now type the following commands and study the output.
root@d213f10c91f9:/# roscore
bash: roscore: command not found
root@d213f10c91f9:/# ros2core
bash: ros2core: command not found
root@d213f10c91f9:/# ros2 core
usage: ros2 [-h] Call `ros2 <command> -h` for more detailed usage. ...
ros2: error: argument Call `ros2 <command> -h` for more detailed usage.: invalid choice: 'core' (choose from 'daemon', 'extension_points', 'extensions', 'launch', 'lifecycle', 'msg', 'node', 'param', 'pkg', 'run', 'service', 'srv', 'topic')
root@d213f10c91f9:/# ros2 master
usage: ros2 [-h] Call `ros2 <command> -h` for more detailed usage. ...
ros2: error: argument Call `ros2 <command> -h` for more detailed usage.: invalid choice: 'master' (choose from 'daemon', 'extension_points', 'extensions', 'launch', 'lifecycle', 'msg', 'node', 'param', 'pkg', 'run', 'service', 'srv', 'topic')
You may want to try other commands to find roscore in ROS2, but I’m done here. ?
Conclusion:could not find roscore in ROS2. The rumour appears true after all.
But what happened to roscore – it was the “core” of ROS, so now what? Let’s find out in the next section.
Section 2: ROS2 – ending the ROS “slave trade”
“Hey, are you saying the people of ROS engaged in slave trade?!” Of course not! It’s just a fun way of describing how ROS1 worked. Relieved? ?
So let’s break the news here: roscore is dead in ROS2. It was killed, buried for good, and replaced by a better system. Here are some highlights:
In ROS1, roscore is the master node. Other nodes depend on it. But in ROS2, no more “master” (and “slaves”). Exit roscore. Enter DDS (Data Distribution Service).
In ROS1, roscore drives a client/server (or slave/master) architecture. For ROS2, DDS drives a distributed architecture.
Peer-to-peer communication (not master-slave :D). This sounds more democratic, doesn’t it?
No more single point of failure (fault tolerance). roscore can hold other nodes to ransom in ROS1, but no node can do that in ROS2.
Configurable Quality of Service (QoS). ROS1 provides a “best effort” service, but in ROS2 we can set the QoS required for a specific use case.
ROS2 also uses DDS for serialization and transport, in addition to “discovery”, which was the main function of roscore in ROS1.
In short, in ROS2, DDS is the new Sherrif in town; roscore has been fired!
Wrapping up
You still have your terminal open? Great, let’s see an example of how one of the core functions performed by roscore is ROS1 is now done in ROS2:
root@d213f10c91f9:/# ros2 node list -a
_ros2cli_node_daemon_0
The command above “finds existing nodes, including hidden ones”. In ROS1, roscore, which was a single node, used to rule this space. But no more in ROS2!
Video
Do you prefer to see this post in “audio and video” instead of “black and white”? If yes, the video below is for you. Enjoy!
We want to hear you!
Did you like this post? Whatever the case, please leave a comment in the comments section below, so we can interact and learn from each other.
If you want to learn about other ROS topics, then please let us know on the comments area and we will do a post or video about it.
