Our robot overlords may not take over anytime soon, but when they do, they’ll likely be running ROS. ROS, or Robot Operating System, was launched over a decade ago to unite developers in building “a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behavior across a wide variety of robotic platforms,” as the ROS project page describes. To succeed, ROS has required deep collaboration among a community of roboticist developers, including more recent but significant involvement from AWS engineers like Thomas Moulard and Miaofei Mei.
At AWS, our interest and involvement in the ROS community have evolved and deepened over time, in concert with our customers’ need for a robust, robot-oriented operating system.
Dōmo arigatō, Misutā Robotto
Over the past 10 years, ROS has become the industry’s most popular robot software development framework. According to ABI Research, by 2024 roughly 55% of the world’s robots will include a ROS package. However, getting there has not been and will not be easy.
The ideas behind ROS germinated at Stanford University in the mid 2000s, the brainchild of student researchers Keenan Wyrobek and Eric Berger. Their goal? Help robotics engineers stop reinventing the robot, as it were, given that there was “too much time dedicated to re-implementing the software infrastructure required to build complex robotics algorithms…[and] too little time dedicated to actually building intelligent robotics programs.“ By late 2007/early 2008, they joined efforts with Scott Hassan’s Willow Garage, a robotics incubator, which began funding their robotics work under the auspices of its Personal Robotics Program.
The Robot Operating System (ROS) was born.
Given its academic origins, it’s perhaps not surprising that the original ROS (ROS 1) was mostly inspired by an academic and hobbyist community that grew to tens of thousands of developers. Though there were large industrial automation systems running ROS, ROS 1 didn’t yet yield the industrial-grade foundation that many customers required. Despite thousands of add-on modules that extended ROS 1 in creative ways, it lacked basic security measures and real-time communication, and only ran on Linux. Lacking alternatives, enterprises kept turning to ROS 1 to build large robotics businesses, though evolving ROS 1 to suit their purposes required considerable effort.
By the late 2010s, these industrial-grade demands were starting to strain ROS 1 as the world took ROS well beyond its initial intended scope, as ROS developer Brian Gerkey wrote in Why ROS 2? To push ROS forward into more commercial-grade applications, Open Robotics, the foundation that shepherds ROS development, kicked off ROS 2, a significant upgrade on ROS 1 with multi-platform support, real-time communications, multi-robot communication, small-embedded device capabilities, and more.
Open Robotics opted not to build these capabilities into ROS 1 because, Gerkey notes, “[G]iven the intrusive nature of the changes that would be required to achieve the benefits that we are seeking, there is too much risk associated with changing the current ROS system that is relied upon by so many people.” The move to ROS 2 therefore broke the API upon which the ROS developer community depended, so the ROS community had to start afresh to build out an ecosystem of modules to extend ROS 2, while also improving its stability, bug by bug.
That was when AWS engineers, along with a number of other collaborators, dug in.
While a variety of teams at Amazon had been using ROS for some time, customer interest in ROS motivated a new phase of our ROS engagement. Given the importance of ROS 2 to our customers’ success, the AWS Robotics team went to work on improving ROS. According to AWS engineer Miaofei Mei, an active contributor to ROS 2, this meant that we began in earnest to contribute features, bug fixes, and usability improvements to ROS 2.
Today, the AWS Robotics team actively contributes to ROS 2 and participates on the ROS 2 Technical Steering Committee. With over 250 merged pull requests to the rosdistro and ros2 organization repos, the AWS Robotics team’s contributions run wide and deep, and are not limited to the most recent ROS 2 release (Dashing). In the Dashing release, we have been fortunate to be able to contribute two major features: new concepts for Quality of Service (QoS) callbacks in rclcpp and rclpy, as well as new QoS features for Deadline, Lifespan, and Liveliness policies. In addition, we have made logging improvements (e.g., implementation of rosout and the ability to integrate a third-party logging solution like log4cxx or spdlog), added runtime analysis tools (ROS2 Sanitizer Report and Analysis), and contributed Secure-ROS2 (SROS 2) improvements (like policy generation for securing nodes), among others.
Helping customers, one robot at a time
While AWS actively contributes to ROS 2, we also benefit from others’ contributions. Indeed, the initial impetus to embrace ROS had everything to do with community, recalls AWS RoboMaker product manager Ray Zhu: “ROS has been around for over 10 years, with tens of thousands of developers building packages on it. For us to catch up and build something similar from the ground up would have been years of development work.” Furthermore, AWS customers kept asking AWS to help them with their robotics applications, and would prefer to build on an open industry standard.
To answer this customer request, we launched AWS RoboMaker at re:Invent 2018, with the goal of making it easy to “develop…code inside of a cloud-based development environment, test it in a Gazebo simulation, and then deploy…finished code to a fleet of one or more robots,” as AWS chief evangelist Jeff Barr wrote at RoboMaker’s launch. AWS RoboMaker extends ROS 2 with cloud services, making it easier for developers to extend their robot applications with AWS services such as Amazon Lex or Amazon Kinesis.
For example, AWS RoboMaker customer Robot Care Systems (RCS), which “use[s] robotics to help seniors, people with Parkinson’s disease, and people with disabilities move about more independently,” turned to AWS RoboMaker to extend its Lea robots. The company had ideas it wanted to implement (e.g., the ability to collect and share movement and behavioral data with patients’ physicians), but didn’t know how to connect to the cloud. According to Gabriel Lopes, a control and robotics scientist at RCS, “It was a revelation seeing how easily cloud connectivity could be accomplished with RoboMaker, just by configuring some scripts.”
Additionally, to help accelerate the development of analysis and validation tools in ROS 2 on behalf of AWS customers, the AWS RoboMaker team contracted established ROS community developers like PickNik to assist in porting RQT with enhancements to ROS 2, as detailed by PickNick co-founder Michael Lautman.
Contributing to our robot future
Such open source collaboration is by no means new to AWS, but it’s becoming more pronounced as we seek to improve how we serve customers. Working through Open Robotics means we cannot always move as fast as we (or our customers) would like. By working within the ROS 2 community we ensure that our customers remain firmly rooted in the open source software commons, which enables them to benefit from the combined innovations of many contributors. In the words of AWS engineer (and ROS contributor) Thomas Moulard, “It would be a hard sell for our customers to tell them to trust us and go proprietary with us. Instead, we’re telling them to embrace the biggest robotics middleware open source community. It helps them to trust us now and have confidence in the future.
With AWS initiatives in the ROS community like the newly-announced ROS 2 Tooling Working Group (WG) led by Moulard and other AWS Robotics team members, AWS hopes to attract more partners, customers, and even competitors to join us on our open source journey. While there remain pockets of Amazon teams using ROS purely as customers, the bulk of our usage now drives a rising number of significant contributions upstream to ROS 2.
Why? Well, as mentioned, our contributing back offers significant benefits for customers. But it’s more than that: it’s also great for AWS employees. As Mei said, “It feels good to be part of a community, and not just a company.”
from AWS Open Source Blog