---
# System prepended metadata

title: ROS Summary

---

# ROS Summary

## ROS Nodes
Nodes are information/dataprocessing units. There are three main ways to inspect a ROS node:

1. Simply list all currently running nodes in the terminal:
```
$ rosnode list
```
2. Make a visual graph of all running nodes and their connections:
```
$ rqt_graph
```
3. List information about a specific node in the terminal:
```
$ rosnode info <node_name>
```

## ROS Topics
ROS topics transport information between nodes. There are three main ways to inspect a ROS topic:

1. Display a list of all topics that are currently being exchanged between active nodes:
```
$ rostopic list
```
2. Display information about the data structure of a specific topic:
```
$ rostopic info <topic_name>
```
3. Print the current content of a topic in the terminal:
```
$ rostopic echo <topic_name>
```

**Important detail: Do not forget the "/" before node and topic names!**

## ROS Messages
ROS topics consist of a topic_name and a topic_type which is based on data structures known as **ROS message types**. These message types are defined in message files. For example, the file ``std_msgs/msg/String.msg`` has the message type ``std_msgs/String``.

We can create new message types using already existing derived message types!

Display a list of all packages with messages (e.g. ``std_msgs``).
```
$ rosmsg packages
```
Display a list of all messages (e.g. ``std_msgs/String``).
```
$ rosmsg list
```
Display the fields in a ROS message type (e.g. ``string data``). 
```
$ rosmsg show <message_type>
```

To create a new message file:
```shell
$ roscd <robot_msgs>/msg # navigate to the folder of ROS message types
$ vim <msg_name>.msg
$ cd ..
$ vim CMakeLists.txt # add the name to the add_message_files section 
$ catkin build
```
## ROS Application
There are four fundamental types of ROS nodes that can be used to build a ROS application:
* Publishers
* Subscribers
* Services (server & client)
* Actions (server & client)


### ROS Publisher
A ROS node that generates information is called a publisher. A publisher **sends information** to nodes via topics. With robotics often these publishers are connected with sensors like cameras, encoders, etc.

In fact, you can also publish to a topic from the command line by using the command:
```
rostopic pub <topic_name> <topic_type> <topic_content>
```
### ROS Subscriber

A ROS node that receives information is called a subscriber. It's subscribed to information in a topic and uses topic callback functions to process the received information. With robotics, subscribers typically **monitor** system states such as triggering an alert when the robot reaches joint limits.

A ROS subscriber only processes the data from a topic whenever the topic is refreshed. That's exactly the purpose of having a publish frequency of a ROS Topic. This means, the publisher "refreshes" the data on the topic at the specified frequency. For example, if you published a ROS Topic only once, then the subscriber callback function will also be called only once.

### ROS Services
While ROS topics are useful for monitoring certain values, it can become data inefficient in cases we don't need to continously monitor or publish sensor data.

ROS services implement these request-response type of communications. They consist of two message types: One for requesting data, and one for the response. These services are the gateway to event-based ROS executions. Services are defined in the same package as messages, in their own ``/srv`` folder. For example, the file ``robot_msgs/srv/SetJointCmd.srv`` has the service type``robot_msgs/SetJointCmd``.

ROS services consists of two ROS nodes:
* **Service server** advertises a service, and makes it available to other nodes.
* **Service client** sends a request message to the service server once the service is available.

Displays information about ROS services.
```
rossrv show <msgs_folder>/<srv>
```

A service description file consists of a request and a response msg type, separated by '---'. To create a new  service definition file:
```csv
float64 measurement_metres # Request field
---                        # Demarcation between request and response
float64 measurement_feet   # Response field
bool succes
```
```shell
$ roscd <robot_msgs> # navigate to the folder of ROS message 
$ mkdir srv && cd /srv 
$ gedit <srv_name>.srv
$ cd ..
$ gedit CMakeLists.txt # add the name to the add_service_files() section 
$ catkin build
```
### ROS Actions
OS Actions allow non-blocking execution such that multiple things can happen at the same time. They are a generalized request-response system (as for services): a client-server infrastructure. ROS actions consists of two ROS nodesactions
* **Action server**: A ROS node that advertises an action, so that other nodes can request action goals to be processed.
* **Action client**: A ROS node that sends goal requests to the action server.

```csv
uint32 num_counts     # Goal field (request)
---                   # Separator
string result_message # Result field (response)
---                   # Separator
uint32 counts_elapsed # Feedback field
```
```shell
$ roscd <robot_msgs> # navigate to the folder of ROS message 
$ mkdir action && cd /action 
$ gedit <action_name>.action
$ cd ..
$ gedit CMakeLists.txt # add the name to the add_action_files() section 
$                    # add actionlib and actionlib_mgs to find_package()
$                    # add actionlib_mgs to generate_messages() and catkin_package()
$ gedit package.xml # add actionlib and actionlib_mgs dependencies
$ catkin build
```
## ROS File System
### ROS workspace
A ROS workspace is a folder to organize ROS project files. ROS uses catkin, which is a build tool to compile source files into executable binary files. Your code goes into the src workspace folder and catkin manages the other ones. A **catkin workspace** contains three main spaces:

1. ``/src``: contains source code, this will be your main work folder
2. ``/devel``: contains the executables of your source files f
3. ``/build``: contains the compiled binary files

We will now guide you through the creation of our own catkin workspace in ROS. 

```shell
$ mkdir -p new_ros_ws/src
$ cd new_ros_ws
$ source /opt/ros/noetic/setup.bash #setup the ROS environment
$ catkin init
$ catkin build
$ source ~/new_ros_ws/devel/setup.bash # source your workspace
$ tree -L 1 # show dependencies
```
### ROS packages
ROS packages reside in the 'src' space. In ROS, software is organised in ROS packages. A ROS package typically contains the following things:
- ``CMakeList.txt``
- ``package.xml``
- ``scripts/`` (This folder contains all Python scripts)
- ``src/`` (This folder contains all C++ source files)

To create a new ROS package, we will use catkin:
```shell
$ cd new_ros_ws/src
$ catkin_create_pkg <package_name> <package_deps>
$ rosdep install <package_name> # install ROS package dependencies
$ rosdep install --from-paths . --ignore-src -y # install all ROS package dependencies

```
## ROS Launch Files
ROS launch files allows to start all ROS nodes together in one terminal.

```
roslaunch <package_name> <launch_file.launch>
```

Launch files are located in the `/launch` folder within a ROS package. It is common practice to follow a naming convention of `<package_name>_<file_name>.launch`.



# ROS extras
Retrieve information the robot model in the environment:
```
$ rosservice call gazebo/get_model_state '{model_name: <model_name>}'
```
In order to prevent the shell window from going to the background, you can right-click on the window bar and select `"Always on Top"` option.

```
$ rostopic pub <topic_name> <msg_type> '{<msg_field}'
```

Another option is publish the topic with a specific rate. The following command will publish the command with a specific rate (e.g. 10 Hz)
```
rostopic pub -r 10 <topic_name> <msg_type> '{<msg_field}'
```