by Maggie Maralit
If you’ve ever wanted to develop your own robotic systems or applications, the Robot Operating System (ROS) is how you get started. ROS is a robotics middleware containing a set of diverse software libraries and powerful developer tools from drivers to state-of-the-art algorithms.
We showed how ROS can extend a mobile robots' flexibility, specifically by allowing them to be programmed for new tasks as the need arises in a previous blog. This post will explore how ROS makes mobile robot development a few levels easier.
ROS packages are made up of nodes, which are executable programs that perform a specific task. These nodes may communicate with each other via publishing or subscribing messages made available as topics, or as a request-response task via the use of services.
Figure 1: Basic ROS data flow
The ROS nodes in a mobile robot are mostly drivers, wrappers, applications, or algorithms. While a driver can directly access the hardware, wrappers call on other APIs of a third-party driver that have the necessary hardware implementation access.
For example, in a mobile robot that has multiple sensors and actuators, each can have drivers/wrappers that enable robots to use their features. The processes of sensing and translating data into actions can be linked together to form different algorithms and applications.
Figure 2: Basic ROS nodes in a mobile robot
To visualize this, imagine a very simple robot that can navigate its way from Point A to Point B while avoiding obstacles. This simple robot could have (1) an IMU for localization; (2) a lidar to map its surroundings and avoid obstacles; and (3) a motor control to move its wheels and go to different locations. In that scenario, the ROS diagram would look like this:
Figure 3: Flowchart for an ROS-based simple robot that can go from Point A to Point B while avoiding obstacles
So what exactly is happening here?
ROS drivers access hardware elements and abstract them from the algorithms and applications. In the case of the IMU and lidar, data is read and then broadcast as ROS messages by its corresponding ROS driver. For the motor control, its ROS driver accepts velocity messages as a “command” to move the motors and go to the intended location – however, it also has access to the wheel encoders and can output those wheel odometry messages as well.
The localization algorithm estimates the position and orientation of a robot. First, it calculates the current position of the robot using IMU, lidar, and wheel odometry messages as input. Then, it broadcasts this position as an odometry message, which is picked up by the collision detection algorithm. Finally, results are cross-checked with the message from the mapping algorithm and the lidar message.
The navigation application sends a motion command via the graphical user interface, which offers a means to control the wheels by sending a velocity message to the motor control driver. Known collision points inform the command sending the robot from Point A to Point B.
ROS provides a standard message/framework that enables inter-node communication. Thus, the whole software architecture can be reused and improved by adding more ROS nodes into it, adding greater functionality to simple robots like the one above.
For example, the localization can be made more accurate by adding a sensor fusion and/or a sensor noise filtering algorithm. Or more sensors can be added, such as radar to accommodate poor lighting or time-of-flight (ToF) depth sensing cameras to enable more accurate 3D mapping and collision detection.
Figure 4: An evolved version of the simple robot flowchart
As long as the hardware systems have ROS drivers that make them available for use in any ROS-capable robot, the algorithms and applications that can be developed on such systems are always extensible.
We’ve seen how different ROS drivers can bring out sensor and actuator messages that serve as inputs and outputs of algorithms and applications within a mobile robot. Advanced technology combined with supporting ROS drivers can help developers move away from the myriad software development kits (SDKs) that are needed to make each hardware work. This allows mobile robotics innovators to focus on evaluating new technology immediately, develop advanced algorithms and applications, while avoiding interoperability issues with third-party products.
To deliver this advantage, the ADI Trinamic portfolio combines ADI’s motion control expertise with our analog process technology and power design proficiency. An example integration can be referenced for further reading here and here. Figure 5 shows a high level software architecture of the ADI Trinamic motion control ROS driver.
Figure 5: Software architecture of the Trinamic motion control ROS driver
ROS has applications in multiple fields (consumer, industrial, automotive, etc.) and can be deployed in a variety of platforms (Linux, Windows, MacOS, and some embedded platforms). It is completely open source with commercial options. Support for ROS is abundant due to dedicated resources across the global community, giving users an easier path for their designs and applications.
This blog provided an overview of how ROS can be utilized in mobile robots. The next blog in the series will further explore building the foundations of the overall software architecture in autonomous mobile robots. Learn more about how ADI ROS Drivers can be used at analog.com/mobile-robotics.
