Creating a self-driving, artificially intelligent robot based on the Robot Operating System (ROS) has been a prominent research topic for the past couple of years. Technologies like ROS and its successor ROS-Industrial, have the potential to bring massive disruptions to manufacturing and transportation industries, redefine jobs, improve transportation safety, and reshape the global manufacturing landscape by eliminating advantages for countries that currently exploit labor loopholes.
ROS is not so much an operating system, as it is a code base essentially implemented for writing robot code using a flexible framework. On my robotics team, we created our own semi-autonomous robot for the First Robotics Competition (FRC) last year. We had autonomous modes, which inherently were different profiles with pre-programmed commands that could make the robot perform certain tasks by itself. This year, we have expanded on the autonomous profiles from last year to create a robot that can do every action that is required, and also know exactly what moment the action needs to be executed. We will be entering our self-driving robot into a competition in November to compete against other teleoperated robots.
If a team of high schoolers can create a completely autonomous robot using ROS in two years, what can a team of 5,000 Google employees do in two years? Five years? A decade? Through my work, I can observe the possibilities and concerns that will arise in the future as progress is made towards a more widespread adoption of ROS.
ROS uses TCP/IP data packets for sending standard messages, so each part of the robot can communicate with the others from anywhere in the network. In the scope of FRC, this is extremely beneficial to our team, because the only person trying to control our robot is our own driver. It raises a potentially devastating flaw, however, that must be addressed if ROS is to be used commercially. Since all nodes are constructed the same way, if some malware enters the network, it could potentially infect every node created with identical code. Suppose ROS is used to create a conjunction of nodes that operate a self-driving car. Then, it is reproduced half a billion times to meet the demand for these cars. Now, a saboteur’s malware infects a single autonomous car. Suddenly, they can infect the control systems of every self-driving car ever created with that piece of malware because all the cars have the same ROS node structure.
Any framework similar to ROS has the potential to be massively transformative, if it can overcome this security flaw and also remain feasible for interchangeable communication between the machine and its nodes. To solve this issue, I suggest a hardware based security standard for autonomous machines intertwined with certain software based security improvements that are currently being developed by the Secure ROS project. An example could be something like a Trusted Platform Module (TPM) chip working in collaboration with an arbiter, or gatekeeper. By using an encryption key in the hardware itself, it would be exceedingly difficult for the attacker to gain access to the important parts of the vehicle. The malware, which is most likely software, would have to find a way to somehow access the chip as well as decrypt what is on it. Even if it does, the arbiter, can authorize or restrict access to the system through a software protocol.
From a commercial standpoint, the tremendous prospects that autonomous frameworks have in accelerating advances within the Robotics and Artificial Intelligence field will change the way the economy and society functions all over the world. Right now, open source autonomous frameworks are still mostly experimental, but the development of safeguards to address security concerns will drastically increase commercial adoption, kick-starting an exponential rise in the production of autonomous cars, manufacturing bots, and even the already present delivery drones within a booming industry.