MOV.ai disrupts Autonomous Mobile Robot development with a Robotics Engine Platform that contains everything needed to quickly build, deploy and operate intelligent robots.
This article was originally published in Robotics and Automation News
Over the past year, we have seen the growing adoption of centralized computing in Autonomous Mobile Robot (AMR) fleets. In this article, we ask if this trend is the best approach, especially in advanced deployments with a large number of AMRs and dynamic, non-sterile environments.
Past generations of AMRs, or more accurately Automated Guided Vehicles (AGVs), operated in sterile environments, with physically marked fixed routes and simple, predefined tasks. The computing requirements were almost nonexistent.
Current day AMRs are different.
In the past few years, thanks to increased CPU power and reduced cost of 360 LIDARs, localization algorithms have matured and become less sensitive to dynamic surroundings. This, in turn, led to the successful deployment of mobile robots in new industries where chaos prevails: random boxes, garbage, and pallets surround the robot trajectories, hundreds of humans and vehicles run around the same paths as the robots.
Advanced AMR implementations include a large number of autonomous robots operating in dynamic, non-sterile environments. AMR fleets are expected to offer not just efficiency, but also flexibility and agility.
They are expected to be able to:
All this requires significant processing power. In the next sections, we will look at the typical decision-making performed by mobile robots and AMR fleets, and the pros and cons of centralized and distributed computing when handling these processes.
There is a specific set of decisions that are necessary for AMR fleets, these can be made via either a centralized or a distributed computing system:
Safety – AMR safety is a complex and partly-regulated regime, dealing with different scenarios that may pose a risk to humans. To mitigate such risks, safety frameworks suggest certain hardware that is certified to meet certain performance levels (PL-C, PC-D, etc.) that in turn guarantee that the safety mechanisms function properly even in adverse conditions such as fire and electric malfunctions.
In that sense, the safety hardware in an AMR is not dependent on the software that handles localization and AI. It is an independent subsystem that provides highly reliable performance to guarantee that the vehicle does not injure people. A safety subsystem resides on the robot itself and reports to the OS and high-level software; however, the high-level software usually can not interfere with the safety subsystem.
Localization – Advanced SLAM technologies use input from sensors and cameras and image processing to identify the robot’s location. This action requires both a significant amount of data acquisition and a significant processing resource and at a very high frequency (almost continuous).
Side note – there are a few indoor-GPS systems based on UWB and cameras, which provide an external source of positional information to the robots. These, however, have not gained much popularity, and self-localization is the prevailing method of choice for AMRs.
Path planning – Here too, the goal of advanced AMRs is not to use a standard, predefined route, but to calculate the optimal route between the robot’s current location and its destination. The optimal route may change along the way, depending on newly identified obstacles or accumulating congestion. In addition, the planned turn radius for taking a corner safely may depend on the load size, and safety distances from people and equipment may be extended to account for heavy loads.
Dynamic path planning is performed using data generated locally by the robot and external data sources. The amount of data and required processing power are not very high, but the frequency is.
Risk prevention – An intelligent layer of protection that augments component-level safety. Risk prevention adjusts robot behavior, taking into consideration specific AMR, load, and environmental parameters to ensure smooth and safe operation and add an extra layer of protection to people, equipment, and goods. Examples include obstacle avoidance, turn ratio calculation and speed adjustments. Risk prevention decisions are taken on a local level, based on specific, constantly changing parameters.
Task allocation and prioritization – This is another decision that is different and more complex in advanced AMR implementations. Unlike with AGVs or basic implementations, tasks are not always predefined in advance in the automation process; they may also be generated dynamically by a human or input from other systems and devices. For example, sending a cleaning robot to clear up a spill, going to the charging station or picking up a loaded trolley.
Task allocation and prioritization can also be interdependent. For example, the decision as to whether an AMR should go to the charging station or perform a task depends on the exact battery level, and the power required to perform the task.
The relevant information is derived from numerous data sources. For example, external cameras can indicate traffic, the location of available AMRs is provided by the AMRs, and task priority by the Task Manager. The amount of data, processing power required and frequency are not very high.
Task allocation is a non-trivial mathematical optimization problem that optimizes fleet success KPIs for a given set of static and dynamic constraints
Conflict resolution – This is a new type of decision which results from dynamic rather than predetermined robot behavior. Conflicts can occur when two robots cross paths or plan on using the same route at the same time. The amount of data, processing power required and the frequency of conflict resolution are not low. However, decision speed is essential to avoid idle wait time.
Centralized computing: All AMRs are connected to a central computer (on-prem or cloud-based) that performs all analysis and decisions and transmits them to individual robots. In case of issues or events, the robot will cease all activity until new instructions are received.
Distributed computing: Each AMR receives all available data, performs independent analysis and decision making, and updates the network with the new data.
The processing power required to control and operate an AMR fleet depends on the number of AMRs and the type of processes they run. As noted, advanced path planning for dynamic “dirty” environments requires significant processing and frequent information transfer. In a deployment with dozens or hundreds of AMRs, this amounts easily to a dedicated data center with the related air conditioning and investment in high-availability technology to avoid a single point of failure.
It is worth noting that even in a centralized approach, mapping and localization are performed locally on the AMR due to the high data requirements and time sensitivity. While there are voices who suggest that in the future, when bandwidth and latency allow, they may be performed centrally, we do not consider this a viable option.
The drawbacks of both central and distributed architectures are known to vendors who take steps towards mitigating some of these issues. Some central computing implementations allow robots a certain level of autonomy – for example, within the corridor the computer performs the path planning.
In addition, some tasks such as monitoring, analytics and alerts, or remediation in cases of conflict, are best performed centrally, even in a distributed implementation.
For most aspects of advanced, dynamic AMR implementations there is no other alternative to distributed computing. The large amount of processing power, the number of requests per second, and the network requirements imply prohibitive costs. As a result, centralized AMR deployments place a cap on the recalculation frequency. This places an artificial handicap on AMR capabilities.
However, some functionalities such as monitoring, analytics, alerts, or remediation in cases of conflict are best performed by centralized computing.
Rapid deployment of advanced AMRs in dynamic, brownfield sites that take into consideration the way humans operate, requires hybrid computing, which combines the best of central and distributed computing.