Understanding ROS community level
These are ROS resources that enable a new community for ROS to exchange software and knowledge. The various resources in these communities are as follows:
Distributions: Similar to the Linux distribution, ROS distributions are a collection of versioned meta packages that we can install. The ROS distribution enables easier installation and collection of the ROS software. The ROS distributions maintain consistent versions across a set of software.
Repositories: ROS relies on a federated network of code repositories, where different institutions can develop and release their own robot software components.
The ROS Wiki: The ROS community Wiki is the main forum for documenting information about ROS. Anyone can sign up for an account and contribute their own documentation, provide corrections or updates, write tutorials, and more.
Bug ticket system: If we find a bug in the existing software or need to add a new feature, we can use this resource.
Mailing lists: The ROS-users mailing list is the primary communication channel about new updates to ROS, as well as a forum to ask questions about the ROS software.
ROS Answers: This website resource helps to ask questions related to ROS. If we post our doubts on this site, other ROS users can see this and give solutions.
Blog: The ROS blog updates with news, photos, and videos related to the ROS community (http://www.ros.org/news).
What are the prerequisites to start with ROS?
Before getting started with ROS and trying the code in this book, the following prerequisites should be met:
Ubuntu 14.04.2 LTS / Ubuntu 15.04: We have to use Ubuntu as the operating system for installing ROS. We prefer to stick on to the L.T.S version of Ubuntu, that is, Ubuntu 14.04/14.04.3, or if you want to explore new ROS distribution you can use Ubuntu 15.04.
ROS Jade/Indigo desktop full installation: Install the full desktop installation of ROS. The version we prefer is ROS Indigo, the latest version, Jade, is also supported. The following link gives you the installation instruction of the latest ROS distribution: http://wiki.ros.org/indigo/Installation/Ubuntu.
Running ROS Master and ROS parameter server
Before running any ROS nodes, we should start ROS Master and the ROS parameter server. We can start ROS Master and the ROS parameter server using a single command called roscore, which will start the following programs:
ROS Master
ROS parameter server
rosout logging nodes
The rosout node will collect log messages from other ROS nodes and store them in a log file, and will also rebroadcast the collected log message to another topic. The topic /rosout is published by ROS nodes working using ROS client libraries such as roscpp and rospy and this topic is subscribed by the rosout node which rebroadcasts the message in another topic called /rosout_agg. This topic has an aggregate stream of log messages. The command roscore is a prerequisite before running any ROS node. The following screenshot shows the messages printing when we run the roscore command in a terminal.
The following is a command to run roscore on a Linux terminal:
The following are explanations of each section when executing roscore on the terminal:
In the first section, we can see a log file is creating inside the ~/.ros/log folder for collecting logs from ROS nodes. This file can be used for debugging purposes.
In the second section, the command starts a ROS launch file called roscore.xml. When a launch file starts, it automatically starts the rosmaster and ROS parameter server. The roslaunch command is a Python script, which can start rosmaster and the ROS parameter server whenever it tries to execute a launch file. This section shows the address of the ROS parameter server within the port.
In the third section, we can see the parameters such as rosdistro and rosversion displayed on the terminal. These parameters are displayed when it executes roscore.xml. We can see more on roscore.xml and its details in the next section.
In the fourth section, we can see the rosmaster node is started using ROS_MASTER_URI, which we defined earlier as an environment variable.
In the fifth section, we can see the rosout node is started, which will start subscribing the /rosout topic and rebroadcasting into /rosout_agg.
The following is the content of roscore.xml:
When the roscore command is executed, initially, the command checks the command line argument for a new port number for the rosmaster. If it gets the port number, it will start listening to the new port number, otherwise it will use the default port. This port number and the roscore.xml launch file will pass to the roslaunch system. The roslaunch system is implemented in a Python module, it will parse the port number and launch the roscore.xml file.
In the roscore.xml file, we can see the ROS parameters and nodes are encapsulated in a group XML tag with a "/" namespace. The group XML tag indicates that all the nodes inside this tag have the same settings.
The two parameters called rosversion and rosdistro store the output of the rosversion roslaunch and rosversion -d commands using the command tag, which is a part of the ROS param tag. The command tag will execute the command mentioned on it and store the output of the command in these two parameters.
The rosmaster and parameter server are executed inside roslaunch modules by using the ROS_MASTER_URI address. This is happening inside the roslaunch Python module. The ROS_MASTER_URI is a combination of the IP address and port in which rosmaster is going to listen. The port number can be changed according to the given port number in the roscore command.
Checking the roscore command output
Let's check the ROS topics and ROS parameters created after running roscore. The following command will list the active topics on the terminal:
The list of topics are as follows, as per our discussion on the rosout node subscribe /rosout topic, which have all log messages from the ROS nodes and /rosout_agg rebroadcast the log messages:
The following command lists out the parameters available when running roscore. The following is the command to list the active ROS parameter:
The parameters are mentioned here; they have the ROS distribution name, version, address of roslaunch server and run_id, where run_id is a unique ID associated with a particular run of roscore:
The list of the ROS service generated during the running roscore can be checked using the following command:
The list of services running is as follows:
These ROS services are generated for each ROS node for setting the logging levels.
After understanding the basics of ROS Master, Parameter server, and roscore we can go to the procedure to build a ROS package. Along with working with the ROS package, we can refresh the concepts of ROS nodes, topics, messages, services, and actionlib.
The ROS packages are the basic unit of the ROS system. We can create the ROS package, build it and release it to the public. The current distribution of ROS we are using is Jade/Indigo. We are using the catkin build system to build ROS packages. A build system is responsible for generating 'targets'(executable/libraries) from a raw source code that can be used by an end user. In older distributions, such as Electric and Fuerte, rosbuild was the build system. Because of the various flaws of rosbuild, catkin came into existence, which is basically based on
CMake (Cross Platform Make). This has lot of advantages such as porting the package into other operating system, such as Windows. If an OS supports CMake and Python, catkin based packages can be easily ported into it.
The first requirement in creating ROS packages is to create a ROS catkin workspace. Here is the procedure to build a catkin workspace.
Build a workspace folder in the home directory and create a src folder inside the workspace folder:
Switch to the source folder. The packages are created inside this package:
Initialize a new catkin workspace:
We can build the workspace even if there are no packages. We can use the following command to switch to the workspace folder:
The catkin_make command will build the following workspace:
After building the empty workspace, we should set the environment of the current workspace to be visible by the ROS system. This process is called overlaying a workspace. We should add the package environment using the following command:
This command will source a bash script called setup.bash inside the devel workspace folder. To set the environment in all bash sessions, we need to add a source command in the .bashrc file, which will source this script whenever a bash session starts.
This is the link of the procedure http://wiki.ros.org/catkin/Tutorials/create_a_workspace.
After setting the catkin workspace, we can create our own package that has sample nodes to demonstrate the working of ROS topics, messages, services, and actionlib.
The catkin_create_pkg command is used to create a ROS package. This command is used to create our package in which we are going to create demos of various ROS concepts.
Switch to the catkin workspace src folder and create the package using the following command:
Here is the command to create the sample ROS package:
The dependencies in the packages are as follows:
roscpp: This is the C++ implementation of ROS. It is a ROS client library which provides APIs to C++ developers to make ROS nodes with ROS topics, services, parameters, and so on. We are including this dependency because we are going to write a ROS C++ node. Any ROS package which uses the C++ node must add this dependency.
std_msgs: This package contains basic ROS primitive data types such as integer, float, string, array, and so on. We can directly use these data types in our nodes without defining a new ROS message.
actionlib: The actionlib meta-package provides interfaces to create preemptable tasks in ROS nodes. We are creating actionlib based nodes in this package. So we should include this package to build the ROS nodes.
actionlib_msgs: This package contains standard message definitions needed to interact with the action server and action client.
We will get the following message if the package is successfully created:
After creating this package, build the package without adding any nodes using the catkin_make command. This command must be executed from the catkin workspace path. The following command shows you how to build our empty ROS package:
After a successful build, we can start adding nodes to the src folder of this package.
The build folder in the CMake build files mainly contains executables of the nodes that are placed inside the catkin workspace src folder. The devel folder contains bash script, header files, and executables in different folders generated during the build process. We can see how to make ROS nodes and build using catkin_make.
Topics are the basic way of communicating between two nodes. In this section, we can see how the topics works. We are going to create two ROS nodes for publishing a topic and subscribing the same. Navigate to the chapter_1_codes/mastering_ros_demo_package/src folder for the codes. demo_topic_publisher.cpp and demo_topic_subscriber.cpp are the two sets of code that we are going to discuss.
The first node we are going to discuss is demo_topic_publisher.cpp. This node will publish an integer value on a topic called /numbers. Copy the current code into a new package or use this existing file from the code repository.
Here is the complete code:
Here is the detailed explanation of the preceding code:
The ros/ros.h is the main header of ROS. If we want to use the roscpp client APIs in our code, we should include this header. The std_msgs/Int32.h is the standard message definition of integer datatype.
Here, we are sending an integer value through a topic. So we should need a message type for handling the integer data. std_msgs contains standard message definition of primitive datatypes. std_msgs/Int32.h contains integer message definition:
This code will initialize a ROS node with a name. It should be noted that the ROS node should be unique. This line is mandatory for all ROS C++ nodes:
This will create a Nodehandle object, which is used to communicate with the ROS system:
This will create a topic publisher and name the topic /numbers with a message type std_msgs::Int32. The second argument is the buffer size. It indicates that how many messages need to be put in a buffer before sending. It should be set to high if the data sending rate is high:
This is used to set the frequency of sending data:
This is an infinite while loop, and it quits when we press Ctrl+C. The ros::ok() function returns zero when there is an interrupt; this can terminate this while loop:
The first line creates an integer ROS message and the second line assigns an integer value to the message. Here, data is the field name of the msg object:
This will print the message data. This line is used to log the ROS information:
This will publish the message to the topics /numbers:
This command will read and update all ROS topics. The node will not publish without a spin() or spinOnce() function:
This line will provide the necessary delay to achieve a frequency of 10Hz.
After discussing the publisher node, we can discuss the subscriber node, which is demo_topic_subscriber.cpp. Copy the code to a new file or use the existing file.
Here is the definition of the subscriber node:
Here is the code explanation:
This is the header needed for the subscribers:
This is a callback function that will execute whenever a data comes to the /numbers topic. Whenever a data reaches this topic, the function will call and extract the value and print it on the console:
This is the subscriber and here, we are giving the topic name needed to subscribe, buffer size, and the callback function. We are subscribing /numbers topic and we have already seen the callback function in the preceding section:
This is an infinite loop in which the node will wait in this step. This code will fasten the callbacks whenever a data reaches the topic. The node will quit only when we press the Ctrl+C key.
We have to edit the CMakeLists.txt file in the package to compile and build the source code. Navigate to chapter_1_codes/mastering_ros_demo_package/CMakeLists.txt to view the existing CMakeLists.txt file. The following code snippet in this file is responsible for building these two nodes:
We can add the preceding snippet to create a new a CMakeLists.txt file for compiling the two codes.
The catkin_make command is used to build the package.
We can first switch to workspace:
Build mastering_ros_demo_package as follows:
We can either use the preceding command to build a specific package or just caktin_make to build the entire workspace.
This will create executables in ~/catkin_ws/devel/lib/<package name>.
If the building is done, we can execute the nodes.
First start roscore:
Now run both commands in two shells.
In the running publisher:
In the running subscriber:
We can see the output as shown here:
The following diagram shows how the nodes communicate with each other. We can see the demo_topic_publisher node publish the /numbers topic and subscribe by then demo_topic_subscriber node.
We can use the rosnode and rostopic tools to debug and understand the working of two nodes:
$ rosnode list: This will list the active nodes
$ rosnode info demo_topic_publisher: This will get the info of the publisher node
$ rostopic echo /numbers: This will display the value sending through the /numbers topic
$ rostopic type /numbers: This will print the message type of the /numbers topic
Adding custom msg and srv files
In this section, we can see how to create custom messages and services definitions in the current package. The message definitions are stored in a .msg file and service definition are stored in a srv file. These definitions inform ROS about the type of data and name of data to be transmitted from a ROS node. When a custom message is added, ROS will convert the definitions into equivalent C++ codes, which we can include in our nodes.
We can start with message definitions.
Message definitions have to be written in the .msg file and have to be kept in the msg folder, which is inside the package.
We are going to create a message file called demo_msg.msg with the following definition:
Until now, we have worked only with standard message definitions. Now, we have created our own definitions and can see how to use them in our code.
The first step is to edit the package.xml file of the current package and uncomment the lines <build_depend>message_generation</build_depend> and <run_depend>message_runtime</run_depend>.
Edit the current CMakeLists.txt and add the message_generation line as follows:
Uncomment the following line and add the custom message file:
After these steps, we can compile and build the package:
To check whether the message is built properly, we can use the rosmsg command:
If the content shown by the command and the definition are the same, the procedure is correct.
If we want to test the custom message, we can build a publisher and subscriber using the custom message type named demo_msg_publisher.cpp and demo_msg_subscriber.cpp. Navigate to the chapter_1_codes/mastering_ros_demo_pkg/src folder for these codes.
We can test the message by adding the following lines of code in CMakeLists.txt:
Build the package using catkin_make and test the node using the following commands.
The publisher node publishes a string along with an integer, and the subscriber node subscribes the topic and prints the values. The output and graph are shown as follows:
The topic in which the nodes are communicating is called /demo_msg_topic. Here is the graph view of two nodes:
Next, we can add srv files to the package. Create a new folder called srv in the current package folder and add a srv file called demo_srv.srv. The definition of this file is as follows:
Here, both the Request and Response are strings.
In the next step, we need to uncomment the following lines in package.xml as we did for the ROS messages:
Take CMakeLists.txt and add message_runtime in catkin_package():
We need to follow the same procedure in generating services as we did for the ROS message. Apart from that, we need additional sections to be uncommented as shown here:
After making these changes, we can build the package using catkin_make and using the following command we can verify the procedure:
If we see the same content as we defined in the file, we can confirm it's working.
Working with ROS services
In this section, we are going to create ROS nodes, which can use the services definition that we defined already. The service nodes we are going to create can send a string message as a request to the server and the server node will send another message as a response.
Navigate to chapter_1_codes/mastering_ros_demo_pkg/src and find nodes with the names demo_service_server.cpp and demo_service_client.cpp.
The demo_service_server.cpp is the server and its definition is as follows:
Let's see the explanation of the code:
Here, we included ros/ros.h, which is a mandatory header for a ROS CPP node. The mastering_ros_demo_pkg/demo_srv.h header is a generated header, which contains our service definition and can use this in our code. The sstream.h is for getting string streaming classes:
This is the server callback function executed when a request is received on the server. The server can receive the request from clients having a message type of mastering_ros_demo_pkg::demo_srv::Request and sends the response in the mastering_ros_demo_pkg::demo_srv::Response type:
In this code, the string data "Received Here" is passing to the service Response instance. Here, out is the field name of the response that we have given in the demo_srv.srv. This response will go to the service client node:
This creates a service having a name as demo_service and a callback function is executed when a request comes to this service. The callback function is demo_service_callback, which we saw in the preceding section.
Next, we can see how the demo_service_client.cpp is working.
Here is the definition of this code:
Let's explain the code:
This line creates a service client that has message type mastering_ros_demo_pkg::demo_srv and communicates to a ROS service named demo_service:
This line will create a new service object instance:
Fill the request instance with a string called "Sending from Here":
This will send the service call to the server. If it is sent successfully, it will print the response and request, if it failed, it do nothing:
If the response is received, then it will print the request and the response.
After discussing the two nodes, we can discuss how to build these two nodes. The following code is added to CMakeLists.txt to compile and build the two nodes:
We can execute the following commands to build the code:
To start nodes, first execute roscore and use the following commands:
We can work with rosservice using the rosservice command:
$ rosservice list: This will list the current ROS services
$ rosservice type /demo_service: This will print the message type of /demo_service
$ rosservice info /demo_service: This will print the information of /demo_service
Working with ROS actionlib
In ROS services, the user implements a request/reply interaction between two nodes, but consider if the reply takes too much time or the server is not finished with the given work, we have to wait until it completes.
There is another method in ROS in which we can preempt the running request and start sending another one if the request is not finished on time as we expected. Actionlib packages provide a standard way to implement these kinds of preemptive tasks. Actionlib is highly used in robot arm navigation and mobile robot navigation. We can see how to implement an action server and action client implementation.
Like ROS services, in actionlib, we have to specify the action specification. The action specification is stored inside the action file having an extension of .action. This file must be kept inside the action folder, which is inside the ROS package. The action file has the following parts:
Goal: The action client can send a goal that has to be executed by the action server. This is similar to the request in the ROS service. For example, if a robot arm joint wants to move from 45 degrees to 90 degrees, the goal here is 90 degrees.
Feedback: When an action client sends a goal to the action server, it will start executing a call-back function. Feedback is simply giving the progress of the current operation inside the callback function. Using the feedback definition, we can get the current progress. In the preceding case, the robot arm joint has to move to 90 degrees; in this case, the feedback can be the intermediate value between 45 and 90 degrees in which the arm is moving.
Result: After completing the goal, the action server will send a final result of completion, it can be the computational result or an acknowledgement. In the preceding example, if the joint reaches 90 degrees it achieves the goal and the result can be anything indicating it finished the goal.
We can discuss a demo action server and action client here. The demo action client will send a number as the goal. When an action server receives the goal, it will count from 0 to the goal number with a step size of 1 and with a one second delay. If it completes before the given time, it will send the result, otherwise, the task will be preempted by the client. The feedback here is the progress of counting. The action file of this task is as follows. The action file is named Demo_action.action:
Here, the count value is the goal in which the server has to count from zero to this number. final_count is the result, in which the final value after completion of a task and current_number is the feedback value. It will specify how much the progress is.
Navigate to chapter_1_codes/mastering_ros_demo_pkg/src and you can find the action server node as demo_action_server.cpp and action client node as demo_action_client.cpp.
Creating the ROS action server
In this section, we will discuss demo_action_server.cpp. The action server receives a goal value that is a number. When the server gets this goal value, it will start counting from zero to this number. If the counting is complete, it will successfully finish the action, if it is preempted before finishing, the action server will look for another goal value.
This code is a bit lengthy, so we can discuss the important code snippet of this code.
Let's start from the header files:
The first header is the standard action library to implement an action server node. The second header is generated from the stored action files. It should include for accessing our action definition:
This class contains the action server definition:
Create a simple action server instance with our custom action message type:
Create a feedback instance for sending feedback during the operation:
Create a result instance for sending the final result:
This is an action constructor, and an action server is created here by taking an argument such as Nodehandle, action_name, and executeCB, where executeCB is the action callback where all the processing is done:
This line registers a callback when the action is preempted. The preemtCB is the callback name executed when there is a preempt request from the action client:
This is the callback definition which is executed when the action server receives a goal value. It will execute callback functions only after checking whether the action server is currently active or it is preempted already:
This loop will execute until the goal value is reached. It will continuously send the current progress as feedback:
Inside this loop, it will check whether the action server is active or it is preempted. If it occurs, the function will return:
If the current value reaches the goal value, then it publishes the final result:
In main(),we create an instance of Demo_actionAction, which will start the action server.
Creating the ROS action client
In this section, we will discuss the working of an action client. demo_action_client.cpp is the action client node that will send the goal value consisting of a number which is the goal. The client is getting the goal value from the command line arguments. The first command line argument of the client is the goal value and the second is the time of completion for this task.
The goal value will be sent to the server and the client will wait until the given time, in seconds. After waiting, the client will check whether it completed or not; if it is not complete, the client will preempt the action.
The client code is a bit lengthy, so we will discuss the important sections of the code:
In action client, we need to include actionlib/client/simple_action_client.h to get the action client APIs which are used to implement action clients:
This will create an action client instance:
This line will wait for an infinite time if there is no action server running on the system. It will exit only when there is an action server running on the system:
Create an instance of a goal and send the goal value from the first command line argument:
This line will wait for the result from the server until the given seconds:
If it is not finished, it will preempt the action.
Building the ROS action server and client
After creating these two files in the src folder, we have to edit the package.xml and CMakeLists.txt to build the nodes.
The package.xml file should contain message generation and runtime packages as we did for ROS service and messages.
We have to include the Boost library in CMakeLists.txt to build these nodes. Also, we have to add the action files that we wrote for this example:
We should pass actionlib, actionlib_msgs, and message_generation in find_package():
We should add Boost as a system dependency:
We need to add our action file in add_action_files():
We have to add actionlib_msgs in generate_messages():
We have to add Boost to include the directory:
After catkin_make, we can run these nodes using the following commands:
The output of these process is shown as follows:
The launch files in ROS are a very useful feature for launching more than one node. In the preceding examples, we have seen a maximum of two ROS nodes, but imagine a scenario in which we have to launch 10 or 20Ł nodes for a robot. It will be difficult if we run each node in a terminal one by one. Instead of that, we can write all nodes inside a XML based file called launch files and using a command called
roslaunch, we can parse this file and launch the nodes.
The roslaunch command will automatically start ROS Master and the parameter server. So in essence, there is no need to start the roscore command and individual node; if we launch the file, all operations will be done in a single command.
Let's start creating launch files. Switch to the package folder and create a new launch file called demo_topic.launch to launch two ROS nodes that are publishing and subscribing an integer value. We keep the launch files in a launch folder, which is inside the package:
Paste the following content into the file:
Let's discuss what is in the code. The <launch></launch> tags are the root element in a launch file. All definitions will be inside these tags.
The <node> tag specifies the desired node to launch:
The name tag inside <node> indicates the name of the node, pkg is the name of the package, and type is the name of executable we are going to launch.
After creating the launch file demo_topic.launch, we can launch it using the following command:
Here is the output we get if the launch is successful:
We can check the list of nodes using:
We can also view the log messages and debug the nodes using a GUI tool called rqt_console:
We can see the logs generated by two nodes in this tool as shown here:
Applications of topics, services, and actionlib
Topics, services, and actionlib are used in different scenarios. We know topics are a unidirectional communication method, services are a bidirectional request/reply kind of communication, and actionlib is a modified form of ROS services in which we can cancel the executing process running on the server whenever required.
Here are some of areas where we use these methods:
Topics: Robot teleoperation, publishing odometry, sending robot transform (TF), and sending robot joint states
Services: This saves camera calibration parameters to a file, saves a map of the robot after SLAM, and loads a parameter file
Actionlib: This is used in motion planners and ROS navigation stacks
Tip
The complete source code of this project can be cloned from the following Git repository. The following command will clone the project repo:
Maintaining the ROS package
Most of the ROS packages are released as open source with the BSD license. There are active developers around the globe who are contributing to the ROS platform. Maintaining packages are an important constraint in all software especially open source application. Open source software is maintained and supported by a community of developers. Creating a version control system for our package is essential if we want to maintain and accept a contribution from other developers. The preceding package is already updated in GitHub and you can view the source code of the project at https://github.com/qboticslabs/mastering_ros_demo_pkg
After uploading the code in GitHub, we can see what the procedures are to release our current package to ROS.
Releasing your ROS package
After creating a ROS package in GitHub, we can officially release our package. ROS provides detailed steps to release the ROS package using a tool called bloom (http://ros-infrastructure.github.io/bloom/). Bloom is a release automation tool, designed to make platform-specific releases from the source projects. Bloom is designed to work best with the catkin project.
The prerequisites before releasing the package are as follows:
The following command will install bloom in Ubuntu:
Create a Git repository for the current package. The repository that has the package is called the upstream repository. Here, we already created a repository at https://github.com/qboticslabs/mastering_ros_demo_pkg.
Create an empty repository in Git for the release package. This repository is called the release repository. We have created a package called demo_pkg-release. This package is at https://github.com/qboticslabs/demo_pkg-release.
After meeting these prerequisites, we can start to create the release of the package. Navigate to the mastering_ros_demo_pkg local repository where we push our package code to Git. Open a terminal inside this local repository and execute the following command:
The purpose of this command is, it will create a CHANGELOG.rst file inside the local repository. After executing this command it will show this option:
Continue without -all option [y/N]. Give y here
It will create a CHANGELOG.rst in the local repository.
After the creation of the log file, we can update the Git repository by committing the changes:
Preparing the ROS package for the release
In this step, we are checking whether the package contains change logs, versions, and so on. The following command makes our package consistent and recommended for a release.
This command should execute from the local repository of the package:
The command will set a version tag if there is no current version and commit the changes in the upstream repository.
The following command starts the release. The syntax of this command is as follows:
When this command is executed, it will go to the rosdistro (https://github.com/ros/rosdistro) package repository to get the package details. The rosdistro package in ROS contains an index file, which contains a list of all the packages in ROS. Currently, there is no index for our package because this is our first release, but we can add our package details to this index file called distributions.yaml.
The following message will be displayed when there is no reference of the package in rosdistro:
We should give the release repository in the terminal that is marked in red in the preceding screenshot. In this case, the URL was https://github.com/qboticslabs/demo_pkg-release.
In the upcoming steps, the wizard will ask for the repository name, upstream, URL, and so on. We can give these options and finally, a pull request to rosdistro will be submitted, which is shown in the following screenshot:
The pull request for this package can be viewed at https://github.com/ros/rosdistro/pull/9662.
If it is accepted, it will merge to indigo/distribution.yaml, which contains the index of all packages in ROS.
The following screenshot displays the package as an index in indigo/distribution.yaml:
After this step, we can confirm that the package is released and officially added to the ROS index.
Creating a Wiki page for your ROS package
ROS wiki allows users to create their own home pages to showcase their package, robot, or sensors. The official wiki page of ROS is wiki.ros.org. Now, we are going to create a wiki page for our package.
The first step is to register in wiki using your mail address. Go to wiki.ros.org, and click on the login button as shown in the screenshot:
After clicking on Login, you can register or directly login with your details if you are already registered. After login, press the user name link on the right side of the wiki page as shown in the screenshot:
After clicking on this link, you will get a chance to create a home page for your package; you will get a text editor with GUI to enter data into. The following screenshot shows you the page we created for this demo package:
The wiki page of this package can be viewed at http://wiki.ros.org/qboticslabs.
Argentina
Australia
Austria
Belgium
Brazil
Bulgaria
Canada
Chile
Colombia
Cyprus
Czechia
Denmark
Ecuador
Egypt
Estonia
Finland
France
Germany
Great Britain
Greece
Hungary
India
Indonesia
Ireland
Italy
Japan
Latvia
Lithuania
Luxembourg
Malaysia
Malta
Mexico
Netherlands
New Zealand
Norway
Philippines
Poland
Portugal
Romania
Russia
Singapore
Slovakia
Slovenia
South Africa
South Korea
Spain
Sweden
Switzerland
Taiwan
Thailand
Turkey
Ukraine
United States
Filter
