Modular Robotics Made Easier With ROS

A robot is made up of many hardware components each of which requires its own software. Even a small robot arm with a handful of servo motors uses a servo motor library.

Add that arm to a wheeled vehicle and you have more motors. Then attach some ultrasonic sensors for collision avoidance or a camera for vision. By that point, you’ve probably split the software into multiple processes: one for the arm, another for the mobility, one for vision, and one to act as the brains interfacing somehow with all the rest. The vision may be doing object recognition, something which is computationally demanding and so you now have multiple computers.

Break all this complexity into modules and you have a use case for ROS, the Robot Operating System. As this article shows, ROS can help with designing, building, managing, and even evolving your robot.

What Is ROS?

ROS is a framework consisting of a huge number of libraries and tools specifically for developing robots. It’s open source and most code comes under the BSD license. It’s also community supported.

ROS has been primarily tested on Ubuntu and Mac OS X though the community has also gotten it working on other Linux distributions and is working on Windows. I have the Kinetic release of ROS running under Ubuntu 16.04 on my Raspberry Pi 3B.

Robot arm simulation in Gazebo
Robot arm simulation in Gazebo. Photo from The Construct

Simulating Your Robot

Before you even build your robot, you may wish to first simulate it. For that, you can create a Unified Robot Description Format (URDF) file, which is an XML file that describes your robot in detail. There’s even a URDF exporter add-in available for SolidWorks. You then use it with ROS and the Gazebo robot simulator to see and manipulate your robot on the screen before building anything.

Structuring Things In ROS: Packages

It’s difficult to explain what’s available for ROS without also going over how things are structured.

At the top of the hierarchy, your robot application consists of one or more packages. Packages typically contain code, libraries, datasets, and configuration files. Anything that makes sense to go together as a module would go in a package. Perhaps you’ve dedicated an Arduino Nano to be a servo motor controller. You might put all the files for communicating with that Arduino into their own package.

Running the ROS command, rospack list at the command line lists 229 packages. Here’s a small sample of what came up.

    • joy – ROS driver for a generic Linux joystick
    • serial – a cross-platform, simple to use library for using serial ports
    • tf2 – helps you keep track of multiple coordinate frames over time
    • rosout – system-wide logging mechanism for messages sent to the /rosout topic
    • raspicam_node – package for getting video from the Raspberry Pi Camera
    • eyeball – Pi eyeball package

The raspicam_node package is one I found online and the eyeball package is one I created from scratch.

Packages are contributed by a large community. For example, from hobbyists, there are packages for popular Pololu motor controllers and from the industrial world, there are packages for the KUKA and Baxter robots. Here’s a link to a large list of available packages. Searching online finds more.

Processes Are Nodes

Nodes in ROS

A sufficiently complex robot will require multiple processes, possibly even spread out over different computers. In ROS, each process is a node. A package contains one or more nodes.

For my example, I use raspicam_node which reads from the Pi Camera and produces a compressed stream of video. A node called image_republisher decompresses that video. My eyeball node then processes images from the video. Of course, to do that they need to communicate somehow.

Communicating Between Nodes

ROS provides two mechanisms for nodes to communicate with each other.

ROS example of nodes and topiicsOne is a publish-subscribe mechanism wherein one node publishes that it will have data available. It publishes under a name called a topic. In the example illustrated here, raspicam_node publishes compressed video to the topic, /raspicam_node/image/compressed. A node which wants that data, image_republisher in our example, then subscribes to that topic. When the publisher has a compressed video image ready, the publisher publishes it and the subscriber will receive it.

The other communication mechanism is called services. A server node provides a service and a client node requests that service. As with publish-subscribe, the server makes its service known via a topic name and the client finds the service via that topic. Unlike with publish-subscribe, it’s the client node which initiates the communication. It does so whenever it wants the service.

Note that with both mechanisms the communication is initiated using the topic and not by directly addressing any particular node. If you’re testing different motor controllers, you could write different nodes which all publish using the same topic. Test one at a time and the subscriber will find whichever one happens to be running since it’s doing the look-up using the topic and not any specific motor controller. This is also useful if you decide to change hardware at a later date or will use a stub when hardware is out for maintenance.

ROS also provides some language independence between communicating nodes. ROS supports Python and C++. The publisher can be written in Python and the subscriber can be written in C++, or vice versa. For example, a Python publisher can gather sensor data while a C++ subscriber does the heavy-duty processing whenever there’s data available.

How are the topics mapped to specific nodes? A Master process takes care of that.

Distributed Computing

Momaro, Photo frontiers in Robotics and AI

Nodes can communicate with each other across a network of machines. The Master runs on only one machine. Nodes on all other machines find the Master using an environment variable containing the hostname of the machine which has the Master.

When nodes request to publish or subscribe to a topic they give only the topic name. One day the publishing node may be on one machine and the next it might be on a different machine. Subscribers won’t know this. They’ll simply subscribe to the topic name and the Master takes care of finding the publisher.

As an example, imagine a centaur robot with a torso which can be attached to different mobile platforms. Once physically connected, nodes in the torso have to find the nodes in the mobile platform. If the same topic names are used by all platforms then the nodes will be found regardless of which platform is in use. The robot, Momaro, is shown here for illustration purposes only since it has a permanent base with only one CPU. However, it does use ROS.

Visualization Tools

There are a few useful command line and graphical tools to help with managing and debugging packages, nodes, topics, and communication. A few command line tools are rospack for packages, rosnode, and rostopic.

rqt_graph showing nodes, topics and how they're communicating
rqt_graph showing nodes, topics and how they’re communicating

Rqt_graph gives a graphical display of nodes, topics and how the nodes are communicating with each other. Here we again see that /raspicam_node/image/compressed is the topic to subscribe to for compressed video images from raspicam_node and /raspicam_node/image is for uncompressed images. This display could highlight communication problems.

rqt_console and rqt_logger_level showing possible issues with raspicom_node
rqt_console and rqt_logger_level showing possible issues with raspicom_node

rqt_console and rqt_logger_level together display messages logged from nodes, whether strictly informational, warnings or errors. They’re useful for debugging and troubleshooting.

Modular Robots Welcome

And that’s a large sample of what’s available from ROS for helping you with modularity in your robots, from design and simulation to debugging and troubleshooting.

Do you have a robot which uses ROS? Perhaps you’d care to enter it into the Robotics Module Challenge of the 2018 Hackaday Prize but hurry. the June 4th deadline is fast approaching. And even if you aren’t entering the contest, we’d still like to hear about your experiences with ROS. Let us know in the comments below.

Meanwhile, we’ll leave you with a video montage showing robots that use ROS.

31 thoughts on “Modular Robotics Made Easier With ROS

  1. I got my masters degree in robotics 7 years ago but the longer I live the more I feel that – unless we’re talking industry or military – this whole ‘domestic…’ or ‘service robots’ thing is just a sham designed to scam investors out of their money.

    1. I mean if we’re being grimly realistic and honest with ourselves, almost all speculative technologies only succeed in scamming some investors out of their money in retrospect. That’s why it’s investment and not purchase, which are concepts that people on kickstarter constantly conflate and confuse. It’s a risk.

      Most new ideas don’t quite take off as we expect, and even the ones that do are often not the only iteration of that technology that got funded by investors. Domestic robots may someday still be a thing, but so far all attempts have failed due to the technology, the market, or both not being ready.

      You know what? I lied. Domestic robots have already succeeded, just not in the Rosie-from-The-Jetsons way we expected in our heads. We have robot vacuums, AI assistants, toys like drones, printers (both 2d and 3d), coffee machines, garage doors, self-driving cars (even if they suck at the moment), even networked power outlets could be considered a form of robot. Some of these stretch the definition of robot in what may be bad faith, but some of these are absolutely successful domestic robots that have reached a market share that is significant enough to count.

      If anything, domestic robotics has become so mundane that it slipped into invisibility and we just take it for granted now. But as for the classic robot butler: Give it time. Seven years might seem like an eternity in the realms of computer science, but it’s a little early to call the time of death just yet.

      1. You’ve nailed there – ” If anything, domestic robotics has become so mundane that it slipped into invisibility and we just take it for granted now.”

        The robots we have that work just don’t look like the ones science fiction envisioned.

    2. Perhaps. But while we’re being pessimistic, what do you do with an aging population that doesn’t have enough young people to care for it?

      I’m gonna bet that by the time I’m decrepit (give it 40 years), a good fraction of people my age will be attended to and kept alive/functioning by robots in some form. I don’t really expect them to be humanoid, just a whole bunch of slightly-smart/anticipatory mechanical assistance.

      Extrapolate from dishwashers through roombas to get automated cook+clean+feed then bolt on Siri and you can see where this is going.

      1. And this is not “for rich old people”. These will be industrial-grade robots, purchased by nursing homes, because they’re cheaper in the medium term than paying wages to human nurses/carers.

        1. If they are good enough, they won’t be in nursing homes, but rented to individual service buyers at their respective locations. If I was an entrepreneur, short on cash, I wouldn’t have money to invest in a building and everything that goes with that, but buying/building a couple of rorbo-nurses and starting small, would be a way to finance expansion of my business from the income it generates. Even better if entrepreneur already was a human rent-a-nurse, with experience in the field, then the robots don’t have so sophisticated SW, one human can control them remotely, give them simple assignments they would perform procedurally, etc.

          1. And we have had an elderly care technology industry for quite a long time already.
            Life Alert communication devices, electric chairs and scooters. Etc.
            It seems the current crop of robotics for the elderly is not service based but comfort based: robotic pets is an emerging market.

            ‘in the home’ robotics is divided into to categories:
            Service robots which don’t need to look like anything. Just do a task. And it turns out we don’t have high expectations or demands for them. Thus Romda and Alexa are popular.

            The other is comfort and satisfaction robotics. These need to remind us of something or provide a sensation new are missing from life. Robotic pets fill a social and emotional void. The next stage here will not be making a robot maid that can clean the house. It will be sex bots you can dress like maids

      2. “Perhaps. But while we’re being pessimistic, what do you do with an aging population that doesn’t have enough young people to care for it?”

        New fangled invention known as…sex. Get to it people!

      3. Screw that. I want the rejuvenation pill so I can live in a 20-year-old body indefinitely until I screw up and step in front of a bus in a couple hundred years. (But I’ll still take a house full of robot slaves so I don’t have to do boring stuff like cooking and cleaning.)

  2. ROS is great for getting a robotics project up off the ground quickly. The community support around ROS and sensors people generally go for in robotics is a great resource for getting high level algorithms implemented without getting bogged down in low level protocol hell, even if it is fun/rewarding, sometimes. With flavors being created for use in military (MROS) and industry (IROS) arenas, its defiantly a upcoming framework that I see growing beyond the nearest robotics research labs.

    I’ve personally been involved with development of robot using ROS for a government project and they were very open to the technology and were pleased with the speed and quality of our delivered product.

  3. Good quick and dirty summary. I’ve been using ROS for a few years on UAVs in a university lab. There are many academic papers around using ROS for research — which I feel is it’s best application where you have many changing unknowns. Dive into Google Scholar to find details and applications.

    1. And think in terms of hardware vs software.
      Pixhawk is the hardware (and it’s native firmware has similar framework and modularity as ROS)

      It’s a physical device representing and publishing a variety of nodes:
      Compas, gps acceleration, etc.

  4. If anyone wants to learn to use ROS, I’d heavily recommend taking a look athe robotis turtlebot 3 Emanuel online. It’s meant to teach people to use the turtlebot 3 hardware, but there’s a gazebo simulation package that everything works with so you don’t need the hardware. YouTube Benjamin Bird – I screen grabbed a few things for one of our research projects and put instructions / links to a load of other handy packages too, like frontiers exploration.

  5. “ROS supports Python and C++. ”

    ROS supports Python, C++ and LISP (dagnabit!) as first class languages out of the box. There are packages to allow interaction with services or clients in Java (and possibly other languages) as well.

      1. Realistically, the eco system supports C++ and python alone. Good luck to anyone trying to get anything to work properly in LISP or any other language for that matter.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.