-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathros_tutorial.tex
146 lines (129 loc) · 9 KB
/
ros_tutorial.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
\documentclass[•]{article}
\title{Ros Tutorial}
\author{Mohammadali Varfan}
\usepackage{listings}
\usepackage{underscore}
\newcommand{\mytilde}{\raise.17ex\hbox{$\scriptstyle\mathtt{\sim}$}}
\begin{document}
\maketitle
This is a document for the important tutorials of ROS.
\section{Basics}
\subsection{Concepts}
\begin{itemize}
\item \textbf{Node:}\\
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.
\item \textbf{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 this master.
\item \textbf{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.
\item \textbf{Service:}\\
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 one-way 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
\end{itemize}
\subsection{Important Commands}
\begin{itemize}
\item \textbf{rosmsg}\\
The "rosmsg" command tool can be used to inspect the message header and the field types. The following command helps to view the message header of a particular message:\\
\begin{lstlisting}[language=Python]
$ rosmsg show std_msgs/Header
\end{lstlisting}
\item \textbf{rosrun}\\
This command is used to run an executable inside a package.
\item \textbf{rqt\_graph}\\
The topics are mentioned in a rectangle and nodes are represented in ellipses. The messages and parameters are not included in this graph.
\item \textbf{rosnode info [node\_name]}\\
This will print the information about that node.
\item \textbf{rosnode list}\\
This will list all the running nodes.
\item \textbf{rostopic bw [topic]}\\
This command will display the bandwidth used by the given topic
\item \textbf{rostopic echo [topic]}\\
This command will print the content of the given topic
\item \textbf{rostopic find [message\_type]}\\
This command will find topics using the given message type
\item \textbf{rostopic hz [topic]}\\
This command will display the publishing rate of the given topic
\item \textbf{rostopic info [topic]}\\
This command will print information about an active topic
\item \textbf{rostopic list}\\
This command will list all active topics in the ROS system
\item \textbf{rostopic pub [topic] [message\_type] [args]}\\
This command can be used to publish a value to a topic with a message type
\item \textbf{rostopic type [topic]}\\
This will display the message type of the given topic.
\end{itemize}
\subsection{Creating ROS Workspace}
\begin{itemize}
\item \textbf{Creating Workspace}\\
Build a workspace folder in the home directory and create a src folder inside the workspace folder:\\
\textbf{mkdir home/catkin_ws/src}\\
Switch to the source folder. The packages are created inside this package:\\
\textbf{cd home/catkin_ws/src}\\
Initialize a new catkin workspace:\\
\textbf{catkin_init_workspace}\\
We can build the workspace even if there are no packages. We can use the following command to switch to the workspace folder:\\
\textbf{cd home/catkin_ws}\\
The catkin_make command will build the following workspace:\\
\textbf{catkin_make}\\
\item \textbf{Set Environment Variables}\\
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:\\
\textbf{echo "source \mytilde/catkin_ws/devel/setup.bash" \textgreater \textgreater \mytilde/.bashrc}\\
\textbf{source \mytilde/.bashrc}
\end{itemize}
\subsection{Creating ROS Package}
Switch to the catkin workspace src folder and create the package using the following command:\\
\textbf{catkin_create_pkg [package_name] [dependency1] [dependency2]}\\
\\For building package we use "\textbf{catkin_make}" command in the root directory of ROS ("\mytilde/catkin_ws")
\subsection{ROS Services}
The ROS services are a type request/response communication between ROS nodes. One node will send a request and wait until it gets a response from the other. The request/response communication is also using the ROS message description.\\
Similar to the message definitions using the .msg file, we have to define the service definition in another file called .srv, which has to be kept inside the srv sub directory of the package. Similar to the message definition, a service description language is used to define the ROS service types.
An example service description format is as follows:\\
\vspace{2mm}
\#Request message type\\
string str\\
---\\
\#Response message type\\
string str
\subsection{ROS Nodes}
page 28 / "read from other book because of python".\\
For example, the camera node on a robot could be named "camera", and it could output a message topic named "image" and read a parameter named "frame_rate" to know how fast to send images.\\
\subsubsection{Namespaces and Remapping}
what happens when a robot has two cameras? We wouldn’t want
to have to write a separate program for each camera, nor would we want the output of both cameras to be interleaved on the image topic, since that would require all subscribers to image to have logic that separates the image streams. ROS provides two mechanisms to handle these situations: namespaces and remapping.\\
\\In the previous example, a robot with two cameras could launch two camera drivers in separate namespaces, such as left and right, which would result in image streams named left/image and right/image.\\
\\This avoids a topic name collision, but how could we send these data streams to another program that was still expecting to receive messages on the topic image? One answer would be to launch this other program in the same namespace as the first, but perhaps this program needs to “reach into” more than one namespace. Enter
remapping.\\
\\In ROS, any string in a program that defines a name can be remapped at runtime. As one example, there is a commonly used program in ROS called image_view that renders a live video window of images being sent on the image topic. At least, that is what is written in the source code of the image_view program. Using remapping, we can instead cause the image_view program to render the right/image topic, or the left/image topic, without having to modify the source code of image_view!
\subsubsection{roslaunch}
roslaunch is a command-line tool designed to automate the launching of collections of ROS nodes:\\
\textbf{roslaunch [PACKAGE_NAME] [LAUNCH_FILE_NAME]}\\
\\Launch files are XML files that describe a collection of nodes along with their topic remappings and parameters. By convention, these files have a suffix of .launch.\\
\begin{lstlisting}
<launch>
<node name="talker" pkg="rospy_tutorials"
type="talker.py" output="screen" />
<node name="listener" pkg="rospy_tutorials"
type="listener.py" output="screen" />
</launch>
\end{lstlisting}
Each <node> tag includes attributes declaring the ROS graph name of the node, the package in which it can be found, and the type of node, which is simply the filename of the executable program. In this example, the output="screen" attributes indicate that the talker and listener nodes should dump their console outputs to the current console, instead of only to log files.\\
\subsection{}
\subsection{}
\subsection{}
\section{Manipulation}
\section{Perception}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\subsection{}
\end{document}