Want to work with robots? Learn how to get started working on hardware from a Raspberry Pi to a multi-sensor drone.
Join the DZone community and get the full member experience. Have you ever wondered how robots, which are mechanical objects, are operated? How do the physical is controlled by the virtual? Well, there are several software middleware libraries in the market that provide frameworks for running and managing robotic systems. The term Robot can be obscure, so to clarify: a robot can be a small device like Raspberry Pi, a more complex one like a drone, or another sophisticated multi-sensor mechanical robot. What’s the benefit of using a middleware? The main benefit is the standardization of interacting with the robot; thus, it alleviates the burden of developing a tailored set of commands for each robot type. It also provides the necessary level of abstraction for working with robots. Designing, operating, and maintaining the application become easier using the toolset of such middleware. This benefit becomes substantial when your system is composed of multiple components or requires coordination between multiple robots. One of the most popular robotics middleware is ROS (Robot Operating System); this article focuses on ROS foundations, setting up ROS environment, and running a sample application. ROS is a framework to develop, build, and deploy software for robotics; its name may be misleading since it’s not a classic operating system but a meta-OS. ROS aims to be a plug-and-play framework for communicating with robots or devices. You don’t have to worry about the robot’s hardware since ROS provides a unified interface to activate the robot’s hardware. So, the software becomes the focus instead of interfacing with specific hardware API. ROS becomes an industry-standard; the days it was used only at the academy are over. It is a cross-product platform and a mature framework; with the rise of its next-generation (ROS2) it is more robust. ROS provides essential functions for developing robot application software that includes data reception, scheduling, error handling, and more. ROS also has a huge supporting community that creates a valuable ecosystem, with extensive documentation, utilities, and tools. This framework is officially supported on Linux (Ubuntu, Debian), but can be installed on other popular operation systems, like Windows OS, Mac OS, and even mobile devices (Android, iOS). ROS framework is supported by C++ and Python, but older versions have ROS implementation in Java (not supported in all ROS distributions). Besides operating robots via code, ROS has a vast CLI API, so you can review the application’s status, its messages, and even send commands without changing a single line of code. Many distributions of ROS were released throughout the years, whilst ROS continues to grow and involve (see its packages‘ usage). ROS community declares in advance the End of Life (EOL) for each version, which should be a consideration whether to use this version or not. Currently, the majority of the distributions is based on the first generation of ROS (aka ROS1). ROS framework was originally founded based on these principles: As you can see, these principles are outdated and do not meet the contemporary use cases and do not align with new technologies; that is the motivation for RO2. Although this article does not delve into ROS2 implementation, it’s worth mentioning the future of ROS. To recap, ROS challenges are: To alleviate these pain-points, and to cope with the changes in the industry, RO2 has arisen. ROS2 presents some major improvements: The ROS team has decided to build ROS2 as a parallel framework to ROS rather than enhancing the current ROS’s libraries (read more about ROS2 and the considerations behind its crafting). So, ROS2 is developed from scratch. You can read more about ROS2 concepts here. A ROS-based application is composed of nodes; each node is a process that runs in a computer. The nodes must register themselves into the ROS master node, which is the core that runs the application. Therefore, the master node must run first. The master is used for administration; a node must register itself before it can be active. The node sends its info to the master first, and then it can communicate with other nodes (see Communication patterns in the next chapter). The interprocess communication is based on ROS implementations of TCP or UDP protocol. Once the nodes‘ communication is established, the master node has finished its part; the nodes communicate independently. However, if the communication is broken, it can be resumed only if the master node is alive. This topology creates a single point of failure if the master is down or inaccessible. ROS has an extensive library that allows communication between nodes. This communication between based on messages, which is the data that is transferred between nodes. In some scenarios, multiple nodes can receive the same data from the sender. ROS is flexible in terms of the programming language; nodes written in different languages can communicate as long as the message structure and data are valid. There are three main communication approaches: This communication pattern is the most common. It is similar to a service bus communication pattern. There is a node that functions as a publisher and posts messages into a channel (topic in ROS terminology); other nodes can subscribe to this channel. The communication is one-way: the publisher transmits data to whoever is subscribed to its channels. The publisher and the subscriber are not aware of each other; it is a decoupled communication pattern. The master node functions as a DNS server.
