Snapdragon and Qualcomm branded products are products of
Qualcomm Technologies, Inc. and/or its subsidiaries.
“Robot” is a Czech word meaning “assistant” or “worker.” For nearly 100 years, people have been perfecting robots for applications as diverse as industrial assembly, food preparation, household assistance and autonomous vehicles for land, sea and air.
Most robots are designed to automate the execution of a dirty, dull, dangerous or difficult task. They have built-in intelligence and are capable of working on their own or with minimal human intervention.
Robotic computing platforms
Platforms and frameworks for robotic computing include:
- Robot Operating System (ROS)
- YARP: A Reverse Proxy (YARP)
- Mobile Robot Programming Toolkit (MRPT)
- Open Robot Control Software (Orocos)
- Microsoft Robotics Studio
This blog explores ROS. On QDN you’ll also find learning resources on how to install ROS on the Qualcomm® Robotics RB3 Platform, how the Qualcomm Robotics RB3 drives the Turtlebot 3 Burger and how to use AWS Robomaker to deploy applications to the Qualcomm Robotics RB3.
Overview of ROS
ROS.org defines the Robot Operating System (ROS) as “a set of software libraries and tools that help you build robot applications. From drivers to state-of-the-art algorithms, and with powerful developer tools, ROS has what you need for your next robotics project. And it's all open source.”
By facilitating standardization, ROS represents a major step towards the development of collaborative, interoperable robotics applications. Its open source nature means that developers need not spend precious time grokking or reinventing the common, complex aspects of robotics. ROS provides useful, reusable, open source packages for operations such as object detection, avoidance, maps and navigation to motivated developers from beginners to experts.
Although ROS stands for “Robotic Operating System,” it is not an operating system as such but rather a framework or platform for building robotics applications and managing packages. ROS supports programming in Python, C++ and Lisp and its primary goal is to allow developers to distribute and reuse interoperable code.
Like any other Linux package of libraries and tools, ROS distributions can be installed off the shelf to most Linux-based operating systems (like Ubuntu). ROS distributions are available for x86, armhf and ARM64 architectures.
Documentation in more than a dozen languages makes it easy to learn about ROS and start developing.
ROS nodes — Interaction and communication
By design, a typical ROS application breaks down into loosely coupled processes (ROS nodes) that can run independently. Nodes register, interact, store and retrieve information through the ROS framework. Thus, a ROS application structure resembles a graph, with nodes as vertices of the graphs. The edges themselves are the mechanisms ROS provides for application interaction.
There are two ways ROS nodes can interact with one another:
- One-way, pub/sub message passing — A node in the graph publishes information on a topic to which one or more nodes have subscribed.
- Synchronous, reliable RPC between nodes — Referred to as a service in ROS, nodes expose services that other nodes can learn about and invoke. That allows reliable, synchronous, two-way communication between nodes.
It is also possible to store information to and retrieve it from a central parameter server. (For more details, see “ROS Computation Graph Level.”)
The figure below depicts a ROS graph designed for pub/sub-style interaction.
Oval shapes represent nodes, rectangles are topics. Here, /number_publisher publishes on topic /number, to which /number_subscriber subscribes. Any information published on the topic /number will be delivered to all subscribers. Similarly, /number_subscriber publishes logging/debug information on the topic /rosout, to which the node /rosout (the default node provided for logging in the ROS framework) has subscribed. Node /rqt_gul_py_node_17778 also publishes on the topic /rosout. Messages published on a topic are delivered directly to the subscriber without the need for an intermediate broker to relay them.
(Note that in ROS, resource names such as nodes, topics and services follow a hierarchical naming pattern. For example, /number_subscriber is not the same resource/node as /app/number_subscriber. Application developers can plan and provide meaningful resource names that reflect the overall hierarchy in their project, as described in the ”Names” section of “ROS Concepts.”)
Consider this application of pub/sub interaction in a self-driving robot. To avoid objects in the path of the robot, the application comprises
- a sensor with a depth-sensing camera that sends periodic information on the distance of objects in the field of view
- a driver that drives the robot.
In a ROS application, the sensor and driver can be implemented as independent ROS nodes interacting over pub/sub. The sensor would publish depth information and the driver would subscribe to and use it to avoid collisions as it drives the robot.
roscore — This is the main ROS component that needs to be started first and which is essential for all other ROS applications (runtime) to work. roscore launches ROS master, a name service that runs on a designated port (most often 11311) and provides services for registration and lookup of topics and services. It allows nodes to look up and find peer nodes to establish connections; once those connections are made, nodes interact directly without the intervention of the ROS name service. The ROS name service makes callbacks to registered nodes upon availability of new nodes, topics and services so that interested nodes can connect. TCPROS is the most common protocol used in ROS.
Parameter server — Running master roscore provides a parameter server that nodes can use to store and retrieve information by key with application-wide access.
ROS_MASTER_IP — Through this environment variable, the ROS master name service supplies information about its location and port number to the application nodes. Nodes then register with the ROS master name service using a unique name (identifier). They also inform about and register any topics they publish or subscribe to and any services they expose. The ROS master name service uses the identifiers to scan its registry for peer nodes that have subscription or service requirements matching the newly registered information. It then makes callbacks to inform the nodes, allowing them to make required connections.
Building ROS applications
Several libraries implement the ROS framework and APIs needed to build ROS applications. roscpp is the client library that implements C++ libraries needed to implement ROS nodes. It provides basic APIs:
- to create nodes
- for the ROS namespace
- for registration with the ROS master name service
- to subscribe to and publish on topics
- to define, expose and invoke services
- to store and retrieve information from the parameter server
roscpp is the basic ROS library that needs to be ported for a new hardware platform. rospy is the python version of this client library.
Developers can reuse and implement ROS packages for device drivers or additional functionality. The packages can then be used to implement ROS applications. ROS packages implemented and used in this fashion provide hardware abstraction for ROS applications.
Catkin is the build tool in ROS. It uses the cmake build system to automatically search and find dependencies required to build ROS packages.
Find out more about deploying ROS to the Qualcomm Robotics RB3 development kit. To help you start, we’ve assembled a collection of learning resources on everything from hardware basics to ROS deployments from AWS RoboMaker.
Qualcomm Robotics RB3 is a product of Qualcomm Technologies, Inc. and/or its subsidiaries.