If you are anything like us, you probably have this nagging feeling that the future is now! If not, then we will do our best to change your mind and show you some cool robotics projects in the process.

Do you remember all the buzz about delivery drones being right around the corner, as far back as 2013, but to this day you’ve never had a package delivered by a drone? Well, in some countries, drone deliveries form a core logistic network.

To date, Zipline drones have made over 288,000 deliveries, mainly in Rwanda and Ghana, and covered a distance of 20,618,394 miles. That’s 86 trips to the moon!

Humanoid robots have also made quite a leap in recent years. Below is a comparison of state-of-the-art humanoid robots dancing in 2015 versus 2020.

When it comes to space, not only do we have a drone on Mars that has performed 28 flights to date, but we can land on an asteroid, pick up samples and come back. We also have some cute flying cubes aboard the International Space Station (ISS) that have been developed to help astronauts with their day-to-day tasks.

The interesting thing about these little helpers is that their code is open-source and is using the Robot Operating System (ROS) – our favorite framework for creating robotic prototypes.

Introduction to ROS

Contrary to what the name suggests, a Robot Operating System is not an OS, but rather a framework that provides open-source tools and libraries for developing robots. ROS gained a lot of popularity not only in academia but also in the industry. According to 2021 metric reports, official ROS documentation had over 130,000 visitors in the reported year, with over 19,000 different packages that were downloaded 595,524,493 times. The original paper that introduced ROS has been cited 9260 times (25% year-over-year increase).

If the numbers alone don’t convince you, then you can take a look at the ROS2 Steering Committee that consists of 19 companies, most of which you will probably recognize.

What we love about ROS is its composability. Having a set of standards in the form of standard messages and a set of good practices in the form of REPs is an actual game changer. Before we consider an example, where composability comes in really handy, let’s have a look at some ROS-specific definitions (source: ROS wiki):

• Nodes: A node is an executable that uses ROS to communicate with other nodes.
• Messages: ROS data type used when subscribing or publishing to a topic.
• Topics: Nodes can publish messages to a topic, as well as subscribe to a topic to receive messages.
• Packages: A way to organize software in ROS. A package can contain nodes, message definitions, libraries, datasets etc.

Scenario for a ROS Application

Imagine the following scenario: you are working on a multirotor to use a laser scanner for creating a 3D map of buildings. In this scenario, one of the most important sensors for you will be a LiDAR scanner. With a monolithic architecture, you would need to start reading frames of data, parse them, make sure your laser readings trigger the right callbacks and not break anything else in your system due to some odd timing issues.

With ROS, the first thing you would do is check if there are any open-source packages for your LiDAR (for most brands this will be the case). As soon as you install the package and run it, you can expect to start receiving data in a known format (sensors_msgs/LaserScan) and you can visualize it with RVIZ, one of ROS’s introspection tools, straight away. If everything went smoothly, this would have taken 10-15 minutes.

Imagine another situation: you are working on a multirotor from the previous example and due to a sudden change in requirements, you have to change the LiDAR to a completely different model from a different manufacturer. In the case of monolithic software, you would be very close to being back to square one. With ROS, however, it’s enough to be able to substitute the LiDAR package and you are good to continue prototyping!

What we find really cool is how ROS enables you to change parameters on the fly for hardware drivers implementing the `dynamic_reconfigure` apk package. It’s enough to just launch `rqt_reconfigure` and we can tune all the dynamic parameters exposed by every node. Talk about the power of standards.

That’s all from us for now! If you liked our hypothetical multirotor project then stay tuned for our next blog post in which we will architect one.

About Adinkra

Adinkra is an R&D engineering firm helping customers create state of the art robotics and AI products while minimizing costs and time to market. We combine a world-class engineering team with a flexible project management framework to offer a one-stop development solution and unlock your product’s full potential for your customers.

Learn more at adinkratech.com.