rospack depends1 beginner_tutorials
roslaunch -v package-name launch-file-name
roslaunch -screen package-name launch-file-name
xterm -e rosrun package node
rosrun turtlesim turtlesim_node turtle1/pos:=tim<remap from="org-name"to "new-name">
rosrun turtlesim turtlesim_node
rosrun rqt_graph rqt_graph
rosparam get param_name
rosparam set param_name
rosnode info node-name
$ rosrun rqt_plot rqt_plot
$ rostopic type /turtle1/cmd_vel
rostopic pub topic [args]
rostopic echo [topic]
rostopic echo /turtle1/cmd_vel
rosrun rqt_tf_tree rqt_tf_tree
rostopic list -v
rostopic echo /first -n 1 --noarr 找到frame id
rostopic info topic-name
rostopic echo topic-name -n 1 --noarr
rostopic pub -r rate-in-hz topic-name message-type message content
$ rostopic find /message_type:
$ rosmsg show geometry_msgs/Twist
$ rosmsg list: This lists all message
$ rosmsg package [package_name]: This lists messages in a package
$ rosbag record topic_name -o bag_name
We can also record all topics using the -a argument.`
$ rosbag play [bag_name]: This will playback the existing bag file.
rosbag info NAME
rosbag play NAME
The following are abstracts of each graph’s concepts:
- Nodes: Nodes are the process that perform computation. Each ROS node is written
using ROS client libraries such as roscpp and rospy. Using client library APIs, we
can implement different types of communication methods in ROS nodes. In a robot,
there will be many nodes to perform different kinds of tasks. Using the ROS
communication methods, it can communicate with each other and exchange data.
One of the aims of ROS nodes is to build simple processes rather than a large process
with all functionality. Being a simple structure, ROS nodes are easy to debug too.
Master: The ROS Master provides name registration and lookup to the rest of the
nodes. Nodes will not be able to find each other, exchange messages, or invoke
services without a ROS Master. In a distributed system, we should run the master on
one computer, and other remote nodes can find each other by communicating with
- Parameter Server: The parameter server allows you to keep the data to be stored in
a central location. All nodes can access and modify these values. Parameter server is
a part of ROS Master
- Messages: Nodes communicate with each other using messages. Messages are
simply a data structure containing the typed field, which can hold a set of data and
that can be sent to another node. There are standard primitive types (integer, floating
point, Boolean, and so on) and these are supported by ROS messages. We can also
build our own message types using these standard types.
- Topics: Each message in ROS is transported using named buses called topics. When
a node sends a message through a topic, then we can say the node is publishing a
topic. When a node receives a message through a topic, then we can say that the node
is subscribing to a topic. The publishing node and subscribing node are not aware of
each other’s existence. We can even subscribe a topic that might not have any
publisher. In short, the production of information and consumption of it are
decoupled. Each topic has a unique name, and any node can access this topic and
send data through it as long as they have the right message type.
- Services: In some robot applications, a publish/subscribe model will not be enough if
it needs a request/response interaction. The publish/subscribe model is a kind of oneway
transport system and when we work with a distributed system, we might need a
request/response kind of interaction. ROS Services are used in these case. We can
define a service definition that contains two parts; one is for requests and the other is
for responses. Using ROS Services, we can write a server node and client node. The
server node provides the service under a name, and when the client node sends a
request message to this server, it will respond and send the result to the client. The
client might need to wait until the server responds. The ROS service interaction is
like a remote procedure call.
- Bags: Bags are a format for saving and playing back ROS message data. Bags are an
important mechanism for storing data, such as sensor data, which can be difficult to
collect but is necessary for developing and testing robot algorithms. Bags are very
useful features when we work with complex robot mechanisms.
The source space contains the source code of catkin packages. This is where you can extract/checkout/clone source code for the packages you want to build. Each folder within the source space contains one or more catkin packages. This space should remain unchanged by configuring, building, or installing. The root of the source space contains a symbolic link to catkin’s boiler-plate ‘toplevel’ CMakeLists.txt file. This file is invoked by CMake during the configuration of the catkin projects in the workspace. It can be created by calling catkin_init_workspace in the source space directory.
The build space is where CMake is invoked to build the catkin packages in the source space. CMake and catkin keep their cache information and other intermediate files here. The build space does not have to be contained within the workspace nor does it have to be outside of the source space, but this is recommended.
build 目录是build space的默认所在位置，同时cmake 和 make也是在这里被调用来配置并编译你的程序包。
The development space (or devel space) is where built targets are placed prior to being installed. The way targets are organized in the devel space is the same as their layout when they are installed. This provides a useful testing and development environment which does not require invoking the installation step. The location of the devel space is controlled by a catkin specific CMake variable called CATKIN_DEVEL_PREFIX, and it defaults to/develspace. This is the default behavior because it might be confusing to CMake users if they invokedcmake .. in a build folder and that modified things outside of the current directory. It is recommended, however, to set thedevel space directory to be a peer of the build space directory.
devel 目录是devel space的默认所在位置, 同时也是在你安装程序包之前存放可执行文件和库文件的地方。
Once targets are built, they can be installed into the install space by invoking the install target, usually with make install. The install space does not have to be contained within the workspace. Since the install space is set by theCMAKE_INSTALL_PREFIX, it defaults to /usr/local, which you should not use (because uninstall is near-impossible, and using multiple ROS distributions does not work either).
When ever referring to a folder which can either be a development space or an install space the generic term result spaceis used.
这会生成两个可执行文件, talker 和 listener, 默认存储到devel space目录,具体是在~/catkin_ws/devel/lib/中.
所有在msg路径下的.msg文件都将转换为ROS所支持语言的源代码。生成的C++头文件将会放置在~/catkin_ws/devel/include/beginner_tutorials/。 Python脚本语言会在~/catkin_ws/devel/lib/python2.7/dist-packages/beginner_tutorials/msg 目录下创建。 lisp文件会出现在~/catkin_ws/devel/share/common-lisp/ros/beginner_tutorials/msg/ 路径下.
config: All configuration files that are used in this ROS package are kept in this
folder. This folder is created by the user and is a common practice to name the folder
config to keep the configuration files in it.
include/package_name: This folder consists of headers and libraries that we need to
use inside the package.
scripts: This folder keeps executable python scripts. In the block diagram, we can
see two example scripts.
src: This folder stores the C++ source codes. We can see two examples of the source
code in the block diagram.
launch: This folder keeps the launch files that are used to launch one or more ROS
msg: This folder contains custom message definitions.
srv: This folder contains the service definitions.
action: This folder contains the action definition. We will see more about actionlib
in the upcoming sections.
package.xml: This is the package manifest file of this package.
CMakeLists.txt: This is the CMake build file of this package.
“Mastering ROS for Robotics Programming(PACKT, 2015).pdf”
Build Tool Dependencies specify build system tools which this package needs to build itself. Typically the only build tool needed is catkin. In a cross-compilation scenario build tool dependencies are for the architecture on which the compilation is performed.
Build Dependencies specify which packages are needed to build this package. This is the case when any file from these packages is required at build time. This can be including headers from these packages at compilation time, linking against libraries from these packages or requiring any other resource at build time (especially when these packages are find_package()-ed in CMake). In a cross-compilation scenario build dependencies are for the targeted architecture.
Run Dependencies specify which packages are needed to run code in this package, or build libraries against this package. This is the case when you depend on shared libraries or transitively include their headers in public headers in this package (especially when these packages are declared as (CATKIN_)DEPENDS in catkin_package() in CMake).
Test Dependencies specify only additional dependencies for unit tests. They should never duplicate any dependencies already mentioned as build or run dependencies.
- Required CMake Version (cmake_minimum_required)
- Package Name (project())
- Find other CMake/Catkin packages needed for build (find_package())
- Enable Python module support (catkin_python_setup())
- Message/Service/Action Generators (add_message_files(), add_service_files(), add_action_files())
- Invoke message/service/action generation (generate_messages())
- Specify package build info export (catkin_package())
- Libraries/Executables to build (add_library()/add_executable()/target_link_libraries())
- Tests to build (catkin_add_gtest())
- Install rules (install())