MOV.ai disrupts Autonomous Mobile Robot development with a Robotics Engine Platform that contains everything needed to quickly build, deploy and operate intelligent robots.
When warehouse operators decide to introduce robots to handle a workload, they usually focus on the business process they wish to automate—for example, the logic of how many boxes need to be moved per hour or per day, and what the alternative costs would be for moving those boxes. They also consider work processes such as how the robots will work alongside human employees, as in bringing them what is needed while also staying out of their way. They analyze the functional requirements, buy the robots and deploy them in the warehouse
But very quickly they realize that managing a fleet of robots—at scale—requires the establishment of processes, custom tools and principles for effective management and maintenance.
Over the past decade, industrial use of robots has shifted in three significant ways:
These advances have one thing in common: software.
Autonomy, communication, decision making, flexibility are all the result of the growing role software is playing in robotics. Another thing these advances have in common is that they add complexity to ongoing operations.
These two factors have opened up an entirely new profession: RobOps.
As warehouses and production floors increase the complexity and variety of tasks performed by robots, they are faced with an expanding world of opportunities as well as a variety of new challenges that give birth to a new discipline: Robot Operations, or RobOps.
RobOps professionals are responsible for the interoperability, upgrades, coordination and security of robots within the production facility. RobOps requires systems thinking and considering different points of potential failure, such as WiFi outages, mechanical failures and disaster recovery. Similar to DevOps, RobOps deals with complexity and uncertainty, and need to be agile to adapt to the changing needs of the organization.
Just as DevOps has become a key role in the orchestration, integration and implementation of software systems, RobOps is critical in the orchestration and implementation of robots.
Let’s look at a few examples of the challenges RobOps needs to handle:
Whether it’s a small production floor or a large robot fleet, wherever there are Autonomous Mobile Robots (AMRs) or multiple robots working together, RobOps needs to address the following four challenges:
Today’s AMRs are full computing systems on wheels. In addition to an operating system, software and internet connectivity, robots can have dozens of sensors and moving parts, each with its own security and software protocols. Everything from sensor firmware to motor control drivers needs upgrades both for functionality and security purposes. Every time one part of the robot is updated, there’s potential for the functionality to change in ways that might not operate the same as before.
Changes are not only related to the robot itself; they may be a result of changes in procedures, inputs, floor layouts, etc. In today’s fast-changing business environment, all of these changes need to be integrated quickly.
It’s important to have a system that allows upgrades with minimal downtime and the capability for rollback in case anything goes wrong. AMR software can give RobOps teams the ability to make granular upgrades and rollbacks in order to isolate specific issues and minimize disruptions. Typically, the team will upgrade one AMR, then a small group of similar AMRs, and finally the whole fleet once the change is proven stable.
In a complicated environment, the team needs to expect the unexpected. RobOps personnel ensure that there’s support for any issues that come up in day-to-day operations. In addition to software and integration malfunctions, the robot itself can incur physical damage internally or by getting bumped, wet, or tangled with other objects in the area.
Diagnosing a problem requires familiarity with the site and robot’s tasks, good diagnostic tools, and sometimes, simple powers of observation and common sense. For example, Michael Sayre recalls a system where a robot would stop working every day at the same time. When the RobOPs staff checked out the location, they found that the sun coming in at a particular angle caused the malfunction. The solution was simple, but that kind of problem is almost impossible to predict yet almost certain to happen in one form or another, in any environment. The onsite diagnosis and astute powers of observation were the key to finding the problem.
Accidents and malfunctions happen. One of the fundamental principles mentioned in the RobOps Manifesto is recognizing that exceptions happen regularly and that in addition to resolving the problems, it’s important to prevent them from recurring.
In today’s robotic fleet management, one of the popular solutions is Forensic Log Management, which means keeping track of the AMRs’ every move and decision. Then, when needed (accidents, crashes, or any other dire event), the data can be reviewed and analyzed for rollback and future learning. An AMR robot has millions of data points per second, so logging them all is simply unrealistic. At the very least, Forensic Log Management requires a record of where the robot stopped, detected bottlenecks and other important information that can help backtrack what preceded the “bad” event.
The robotics industry is enormous and moving so rapidly that standardization simply isn’t available for all of the operations needed. Every manufacturer and every robot has its own localization methodology, mapping system, and communications.
Each and every one of the challenges is multiplied by the number of robot types, and the complexity is compounded by different robot types.
RobOps also addresses the need to align and configure systems to avoid any interoperability issues.
In short, RobOps deals with the people, processes and tools that are required to scale robot fleets and ensure they are operational and effective 24/7.
In a presentation to iROS, ALOK PATHAK defined it as follows:
The Robot Operations Group manifesto defines the 4 elements of RobOps:
We at MOV.AI believe that effective Robot operations require more than an operational framework. In the same way that DevOps starts with development, so do the foundations for RobOps—they span the realm of both robot development and operations.
Here are some additional aspects that enable seamless 24/7 robot operations:
Here is an example of our software distribution framework:
The implementation of robots and AMR solutions is constantly evolving and growing in scale and complexity. Keeping robots operational and effective 24/7 requires a new approach that covers the product, the team, tools, and processes.