Print this page
Create your ROS packages

Create your ROS packages


ROS (Robot Operating System) is a well-defined framework for robot design. It provides a easy-to-use and multiple-language binding for makers to concentrate on major algorithm implementations, but not routine communication protocols among components. Tons of ROS packages are developed and well-tested, and they are available for free, can save us time and money. Integration with Gazebo and its own visualization tools allow us to do simulation or debug. With C++ as major developing language, it is easy to integration with your favorite toolkits, like OpenCV, PCL, etc. Or, you can use Python to do quick prototypes without long-waiting compiling.
Learning ROS actually covers lots topics, however, you just need to know some basic concepts then you are ok to go. Once you are familiar ROS's concept, working with ROS is just like calling another library. ROS comes with several tutorials in different levels, which are good starting point to get some hints. Here are my experience with ROS from my several projects.
Basic concepts of ROS:
master package node
Master: the only controller of the whole system. It handles how nodes to see each other, and create network tunnels for nodes to communicate each other. Network tunnels can be TCP or UDP. Before all nodes can work, a Master should be run.
Session: The session starts with the spawn of the Master, and ended immediately after Master is down.
Node: The very basic executable component in ROS system. In Linux, a ROS node is an executable program, which contains your project's logic. In a real ROS project, for example, you can have a node to control motors, a node to do lane detection, another node to recognize traffic signs, and another node to capture images. Nodes can exists in a live session, or it won't be able to communicate with other nodes.
Topic: The asynchronized communication among nodes. A node (a publisher node) can “publish” one or more topics, other nodes (subscriber nodes) can “subscribe” these topics. Because it is asynchronized, the publisher node does not hang after a topic is published. The subscriber node will get these topic via a callback function later.
For example, the “Image capture” node publishes topic with image content, then the “lane detection” node, which subscribes this image topic, is called with this image content. Once lane direction is analyzed, “lane detection” node publishes another topic about these lane direction, “motor control” node, which subscribes it, is called with these lane direction then adjusts the motors accordingly. Since it is asynchronized, “Image capture” node won't be hold up while other nodes processing its topic.
Service: It is almost the same as a topic, except in a synchronized communication mode among nodes. Once a node publishes a service, the publisher node will wait till subscriber nodes returns from its callback function along with returned values.
The use case is like, an “Manual-controller” node publishes a “emergency-halt” service to halt the car, the motor-control node receives this service, stops the car, then returns to manual-controller node with return values indicating if motor is stopped or not. During this period, manual-control node is hold up and wait for returning from motor-control node.
Message: It is the basic atom to be pass among nodes subscribing to specific topic or service. A message is actually defined in a text file, then catkin_make build system interprets it and generate C++ header and implementation files for it. 
Parameters: You can define few types of data to be shared among nodes. Parameters can be global or private, which make data sharing easily. For example, you can define some parameters for your lane detection algorithm, and adjust them in different conditions without changing your program frequently.
Some concepts to organize your ROS projects:
Package: A ROS package is a collection of several nodes, which defined by a package manifest file (an xml file.) A package is the only way to share your codes to other ROS projects. So, in a ROS project, you actually define one or more packages first, then create nodes inside these packages. Or, you can reuse other's packages in your projects.
Workspace: A workspace is to create a build environment for ROS's catkin_make build system. A workspace, which is a folder, contains several packages, each of which sit in its own folder. In package folder, you maintain codes for nodes. Then, by using catkin_make, you can build all packages or optionally some packages.
A general folder structure of a ROS workspace is like (I'll put a "/" at the beginning of a folder, that does not mean is it from root of your file system.)
In each package folder (package-1 and package-2), “package.xml” is package manifest file, and “CMakeLists.txt” is the build script for this package. From its name, you can guess it utilizes CMake to build the codes. “/build” and “/devel” are folders where catkin_make put all compiled results. You don't have to create all these folders, ROS provides some tools to create these for you. "/srv" is the folder to store message file for services, while "/msg" is the folder to store message file for topics, you can create these folder when you need them.
Here are some steps to prepare for your workspace and packages
Get all tools to build and compile codes
sudo apt-get install build-essential -y
Create ROS workspace
Create a workspace root folder, in this case “roscar”, and also create a “src” folder under it. This “/src” folder will contain all packages. It is easier to use “src” as its name which is recognized by catkin_make automatically.
mkdir -f roscar/src
Initialize workspace:
cd roscar/src
“catkin_init_workspace” command will create “/build” and “/devel” folder under “/roscar”, also links a generic “CMakeLists.txt” under “/roscar/src” folder.
You can actually compile this workspace now
cd ~/roscar
Once finished, you can find several data generated in “/build” and “/devel” folder. Executable files are generated under "/devel/lib/wheels" folder ("wheels" is package name.) One important file “setup.sh” is created under “/devel” folder. You have to execute this shell script to setup environment variables, so ROS system can recognize your packages.
source devel/setup.sh
or make it in your bash startup
echo "source ~/roscar/devel/setup.sh" >> ~/.bashrc
If your package sources are not under “/src” folder, e.g., under “my_src” folder, then
catkin_make --source my_src
To create a package, for example, to create a package names “wheels”
cd roscar/src
catkin_create_pkg wheels std_msgs rospy roscpp
cd ..
In this example, “catkin_create_pkg” create basic folder structure for package “wheels”, and setup build dependencies “std_msg”, “rospy” and “roscpp”, which are ROS libraries. After “catkin_make” is executed, “wheels” package is built. You can use following command to check (it actually list dependencies of a package.)
rospack depends1 wheels
Then, you begin to add your codes to "/src" folder of a package. As for package manifest file "package.xml", most of the time, you don't have to change it. Please refer to this link for detail. As you add more source files to your package, you have to alter CMakeLists.txt to have them compiled well. Please refer to CMake for ROS for details.
In case you want to put your codes in git, I prefer to map a ROS workspace to a git repository. You can create a new git repository mapping to your ROS workspace like (I use previous workspace folder structure as examples)
from web browser, login to your git account, and create an empty git repository named the same as your ROS workspace ("my_workspace" in this case), so you can have a url for your new created repository as [new_rep_url]. Be sure not to add "README", licenses and .gitignore file at this moment.
Open a terminal, 
cd ~/my_workspace
git init
git add .
git commit -m "First commit for ROS workspace"
git remote all origin [new_rep_url]
git remove -v
git push origin master
Now, you should have connected git repository with your ROS workspace. In order not to add compiled intermediate files to git repository, you had better to add some git ignore rules
create a file ".gitignore_global" under "/my_workspace" folder, or you can edit your git ignore file.
Edit this file and add these lines, or you can refer to some more examples about your cases
then add it as a git global setting
git config --global core.excludesfile ~/my_workspace/.gitignore_global
Last modified on Tuesday, 26 January 2016 20:37

© Copyright 2007- Yi Systems, Inc. All rights reserved.

5009 Asteria St, Torrance, CA, 90503, U.S.A. | +1-310-561-7237 | requestinfo@yisystems.com