ROS Presentation

What is ROS?

What is ROS?

• Essentially, an ROS system can be represented by a graph where the nodes consist of individual programs and the edges are message streams between two nodes

Why ROS? Part 1• Traditional way of programming: sequential• Consequences of sequential programming in robotic context:

– Not able to request actions or commands asynchronously– Not able to stream data to multiple places concurrently

• How does ROS solve this problem?– ROS has individual nodes that communicate with each other

without involving other nodes, as and when a node wants data– This is done through several communication methods namely

topics, services, and actions– ROS involves separate processes or nodes for each component

(may be multiple as well) so they can work independently and thus asynchronously

Why ROS? Part 2• Traditional way of getting different hardware components to

“talk” to each other: each time one component wants to talk to another, their respective APIs have to be imported: lots of dependencies, very messy and complicated

• How ROS solves this problem:– Each node has a particular message type. (uint64, string,

bool, combinations etc.) Nodes with same message types can communicate with each other via topics, services, and actions

– New interface created, abstraction above hardware driver level

Why ROS? Summary

• Modular - event driven, triggers callback function when event is detected; asynchronous, nodes are independent of each other and so messages can be sent between nodes asynchronously, as and when demanded

• Abstraction – interface consisting of message types enabling communication between different hardware components without adding dependencies each time; driver details need not be referenced when communicating between nodes

Getting Started: roscore

• ROS is peer – peer; no central server through which messages are routed

• Roscore provides communication information (TCP port number) to nodes to allow them to transmit messages to each other

• In the beginning, nodes register themselves to roscore and tells it which message it publishes and which nodes it’d like to subscribe to and queries roscore to find other nodes and data streams by name

Getting started: creating a workspace

• catkin is the name of the ROS build system• To create a new workspace, first we have to source ROS to bash, the linux

shell: – source /opt/ros/kinetic/setup.bash

• To make a catkin workspace and initialize it:– mkdir –p ~/catkin_ws/src– cd ~/catkin_ws/src– catkin_init_workspace– catkin_make

• To create a new package:– cd ~/catkin_ws/src– catkin_create-pkg basics(name of package)rospy(dependency)

• Point to note, always source bash when in new terminal by:– source devel/setup.bash

Getting started: running a node

• To run a node: – Rosrun NAMEOFPACKAGE [ARGS]

• Or to run multiple nodes:– Roslaunch NAMEOFPACKAGE LAUNCH_FILE

Topics

Topics

• Topics are a means of communication between two nodes in ROS

• A topic is made up of a topic publisher which publishes the topic and a topic subscriber that subscribes to the topic

• All messages over a topic must be of the same data type

Example of Topic Publisher node

Example of Topic Subscriber node

Latched Topics

• Defining a topic as latched means that the subscriber node gets the last send message from the publisher node

• To do this:– Pub = rospy.Publisher(‘map’, nav_msgs/OccupancyGrid, latched=True)

Defining your own message types

• In a file named <MESSAGENAME>.msg, define message example:

Defining your own message types

• Place file new folder called msg in catkin_ws/src/basics/

• Edit package.xml file in catkin_ws/src/basics/• Add:

– <build_depend>message_generation</build_depend> <run_depend>message_runtime</run-depend>

Defining your own message types• In CMakeList.txt,

– find_package(catkin REQUIRED COMPONENTS rospy std_msgs message_generation #add here )- catkin_package( CATKIN_DEPENDS message_runtime #add here )- add_message_files( FILES Complex.msg )- generate_messages( DEPENDENCIES std_msgs )- Run catkin_make

Services

• Services allow one node to call a function that executes in another node

• Definite inputs and outputs of this function similar to the way we define new message types

• The server node which provides the service specifies a callback to deal with the service request and advertises the service

• The client node which calls the service then accesses this service through a local proxy

Creating a service file

Implementing a Service

Using a service example

Actions

• Actions used in case when the time required for a function to return a value is undetermined

• Actions are implemented using three different topics namely goal, result, and feedback. So it is essentially a higher level protocol that determines how these topics should interact

Defining an action

Defining an action• In CMakeLists.txt,

– Find package(catkin REQUIRED COMPONENTS#other packages already listed here actionlib_msgs )- add_action_files( DIRECTORY action FILES Timer.action )- generate_messages( DEPENDENCIES actionlib_msgs std_msgs )- catkin_package( CATKIN_DEPENDS actionlib_msgs )

Implementing an action server

Using an Action

ROS wrappers

• A wrapper is a node that creates an interface between ROS and another API for example a sensor driver API

• One needs to decide what kinds of messages the wrapper will produce

• It is best to use message types already defined within ROS to make it as broadly useful as possible

Implementing an ROS wrapper

Implementing an ROS wrapper

Questions?

Thank you.