ros

What is ROS?

The Robot Operative System (ROS) is an open-source, meta-operating system for your robot maintained by the Open Source Robotics Foundation (OSRF). It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers. A ROS system is comprised of a number of independent nodes, each of which communicates with the other nodes using a publish/subscribe messaging model.

Why ROS?

ROS is the ultimate SDK for robot application development. It provides a distributed architecture and contains state-of-the art algorithms implemented and maintained by experts in the field. Everything with a permissive license that just in a few years changed the landscape of robotics and has been widely adopted by academia and industry.

Note that nodes in ROS do not have to be on the same system (multiple computers) or even of the same architecture! You could have a Erle-Brain publishing messages, a laptop subscribing to them. ROS is also open source, maintained by many people. This makes ROS really flexible and adaptable to the needs of the user.

A little bit of history?

ROS was originally developed in 2007 by the Stanford Artificial Intelligence Laboratory (SAIL) with the support of the Stanford AI Robot project. As of 2008, development continues primarily at Willow Garage, a robotics research institute, with more than 20 institutions collaborating within a federated development model. In February 2013, ROS stewardship transitioned to the Open Source Robotics Foundation.

ROS is released under the terms of the BSD (Berkeley Software Distribution) license and is an open source software. It is free for commercial and research use

ROS promotes code reutilization so that the robotics developers and scientists do not have to reinvent the wheel all the time. With ROS, you can do this and more. You can take the code from the repositories, improve it, and share it again.

ROS: Concepts

  • Master: The ROS Master provides name registration and lookup to the rest of the Computation Graph. Without the Master, nodes would not be able to find each other, exchange messages, or invoke services.
  • Nodes: Nodes are processes that perform computation. ROS is designed to be modular at a fine-grained scale; a robot control system usually comprises many nodes. For example, one node controls a laser range-finder, one node controls the wheel motors, one node performs localization, one node performs path planning, one Node provides a graphical view of the system, and so on. A ROS node is written with the use of a ROS client library, such as roscpp or rospy.
  • Parameter Server: The Parameter Server allows data to be stored by key in a central location. It is currently part of the Master.
  • Messages: Nodes communicate with each other by passing messages. A message is simply a data structure, comprising typed fields. Standard primitive types (integer, floating point, boolean, etc.) are supported, as are arrays of primitive types. Messages can include arbitrarily nested structures and arrays (much like C structs).
  • Topics: Messages are routed via a transport system with publish / subscribe semantics. A node sends out a message by publishing it to a given topic. The topic is a name that is used to identify the content of the message. A node that is interested in a certain kind of data will subscribe to the appropriate topic. There may be multiple concurrent publishers and subscribers for a single topic, and a single node may publish and/or subscribe to multiple topics. In general, publishers and subscribers are not aware of each others’ existence. The idea is to decouple the production of information from its consumption. Logically, one can think of a topic as a strongly typed message bus. Each bus has a name, and anyone can connect to the bus to send or receive messages as long as they are the right type.
  • Services: The publish / subscribe model is a very flexible communication paradigm, but its many-to-many, one-way transport is not appropriate for request / reply interactions, which are often required in a distributed system. Request / reply is done via services, which are defined by a pair of message structures: one for the request and one for the reply. A providing node offers a service under a name and a client uses the service by sending the request message and awaiting the reply. ROS client libraries generally present this interaction to the programmer as if it were 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, that can be difficult to collect but is necessary for developing and testing algorithms.

 

NODES

Nodes are executables that can communicate with other processes using topics, services, or the Parameter Server. Using nodes in ROS provides us with fault tolerance and separates the code and functionalities making the system simpler.

A node must have a unique name in the system. This name is used to permit the node to communicate with another node using its name without ambiguity. A node can be written using different libraries such as roscpp and rospy; roscpp is for C++ and rospy is for Python.

ROS has tools to handle nodes and give us information about it such as rosnode. The tool rosnode is a command-line tool for displaying information about nodes, such as listing the currently running nodes.

  • rosnode info node: This prints information about the node
  • rosnode kill node: This kills a running node or sends a given signal
  • rosnode list: This lists the active nodes
  • rosnode machine hostname: This lists the nodes running on a particular machine or lists the machines
  • rosnode ping node: This tests the connectivity to the node
  • rosnode cleanup: This purges registration information from unreachable nodes

TOPICS

Topics are buses used by nodes to transmit data. Topics can be transmitted without a direct connection between nodes, meaning the production and consumption of data are decoupled. A topic can have various subscribers.

Each topic is strongly typed by the ROS message type used to publish it, and nodes can only receive messages from a matching type. A node can subscribe to a topic only if it has the same message type.

The topics in ROS can be transmitted using TCP/IP and UDP. The TCP/IP-based transport is known as TCPROS and uses the persistent TCP/IP connection. This is the default transport used in ROS.

The UDP-based transport is known as UDPROS and is a low-latency, lossy transport. So, it is best suited for tasks such as teleoperation.

ROS has a tool to work with topics called rostopic. It is a command-line tool that gives us information about the topic or publishes data directly on the network.

  • rostopic bw /topic: This displays the bandwidth used by the topic.
  • rostopic echo /topic: This prints messages to the screen.
  • rostopic find message_type: This finds topics by their type.
  • rostopic hz /topic: This displays the publishing rate of the topic.
  • rostopic info /topic: This prints information about the active topic, the topics published, the ones it is subscribed to, and services.
  • rostopic list: This prints information about active topics.
  • rostopic pub /topic type args: This publishes data to the topic. It allows us to create and publish data in whatever topic we want, directly from the command line.
  • rostopic type /topic: This prints the topic type, that is, the type of message it publishes.

Services

When you need to communicate with nodes and receive a reply, you cannot do it with topics; you need to do it with services.

The services are developed by the user, and standard services don’t exist for nodes. The files with the source code of the messages are stored in the srv folder.

With rosservice, we can list and query services. The commands supported are as follows:

  • rosservice call /service args: This calls the service with the provided arguments
  • rosservice find msg-type: This finds services by the service type
  • rosservice info /service: This prints information about the service
  • rosservice list: This lists the active services
  • rosservice type /service: This prints the service type
  • rosservice uri /service: This prints the service ROSRPC URI

A Parameter Server is a shared, multivariable dictionary that is accessible via a network. Nodes use this server to store and retrieve parameters at runtime.

ROS has the rosparam tool to work with the Parameter Server. The supported parameters are as follows:

  • rosparam list: This lists all the parameters in the server
  • rosparam get parameter: This gets the value of a parameter
  • rosparam set parameter value: This sets the value of a parameter
  • rosparam delete parameter: This deletes a parameter
  • rosparam dump file: This saves the Parameter Server to a file
  • rosparam load file: This loads a file (with parameters) on the Parameter Server

ROS tools:

To create, modify, or work with packages, ROS gives us some tools for assistance:

  • rospack: This command is used to get information or find packages in the system.
  • roscreate-pkg: When you want to create a new package, use this command
  • rosmake: This command is used to compile a package
  • rosdep: This command installs system dependencies of a package
  • rxdeps: This command is used if you want to see the package dependencies as a graph

To move between the packages and their folders and files, ROS gives us a very useful package called rosbash, which provides some commands very similar to the Linux commands. The following are a few examples:

  • roscd: This command helps to change the directory
  • rosed: This command is used to edit a file
  • roscp: This command is used to copy a file from some package
  • rosd: This command lists the directories of a package
  • rosls: This command lists the files from a package

Configure your network

If you are working with two different machines, for example: Erle-Brain and your laptop remember to configure ROS_MASTER_URI and ROS_IP. Maybe could be interesting to put this lines in your ~/.bashrc.

Erle-Brain:

export ROS_MASTER_URI=http://192.168.7.2:11311
export ROS_IP=192.168.7.2

Laptop or PC:

export ROS_MASTER_URI=http://192.168.7.2:11311
export ROS_IP=192.168.7.1

Practical example

Now that you have installed ROS, to start using it, you must provide your system with the path where ROS is installed. Open a new shell and type the following command

roscore
roscore: command not found

You will see this message because your system does not know where to search for the commands. To solve it, type the following command in a shell:

source /opt/ros/indigo/setup.bash

Then, type the roscore command once again, and you will see the following output:

...
Press Ctrl-C to interrupt

started roslaunch server http://192.168.7.2:52131/
ros_comm version 1.11.10

SUMMARY
========

PARAMETERS
 * /rosdistro: indigo
 * /rosversion: 1.11.10

NODES

auto-starting new master
process[master]: started with pid [5437]
ROS_MASTER_URI=http://192.168.7.2:11311/

setting /run_id to 8e8dcaf5-fd39-11e4-bff2-6c400899ab38
process[rosout-1]: started with pid [5440]
started core service [/rosout]

This means that your system knows where to find the commands to run ROS. Note that if you open another shell and type roscore, it will not work. This is because it is necessary to add this script within the .bashrc file. So, every time you start a new shell, the scripts will run because .bashrc always runs when a shell runs. Use the following commands to add the script:

echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc
source ~/.bashrc

Visualizing a single image

Download and Compile the Source Code

Being an image, we cannot use rostopic echo /camera because the amount of information in plain text would be very huge and also difficult to analyze. For this you will need two terminals. On the first terminal, launch roscore:

roscore

On the second terminal, create a launch file called “usb_cam-test.launch” with the following content (be sure to customize the value of video_device to match your system):

<launch>
  <node name="usb_cam" pkg="usb_cam" type="usb_cam_node" output="screen" >
    <param name="video_device" value="/dev/video0" />
    <param name="image_width" value="640" />
    <param name="image_height" value="480" />
    <param name="pixel_format" value="mjpeg" />
    <param name="camera_frame_id" value="usb_cam" />
    <param name="io_method" value="mmap"/>
  </node>
</launch>
roslaunch usb_cam-test.launch

if you want to visualize the image run in another terminal:

rosrun image_view image_view image:=/camera

Another important utility that ROS gives to the user is the possibility to calibrate the camera. It has a calibration interface built on top of the OpenCV calibration API. This tool is very simple to use; so, once the camera is running, we only have to show some views of a calibration pattern (usually a checkerboard) using this:

rosrun camera_calibration cameracalibrator.py --size 8x6 --square
0.108 image:=/camera/image_raw camera:=/camera

WHAT ARE YOU WAITING FOR?