Autonomous mobile robots (AMR) – a beginner’s guide to adoption
Tags: Automation , guidelines , Open Source Robotics , robotics
Note: This blog follows the autonomous mobile robots structure defined by “Why you’re looking at AGV / AMR technology all wrong” written by Limor Schweitzer.
The process of automation with autonomous mobile robots (AMR) is challenging. Is not only about the budget for companies looking to automate. It also requires a deep understanding of your processes, from material handling to end product. Automation taps into having a broader sense of where you are and where you want to be.
All of this adds complexity to an already demanding task. It starts with, figuring out the type of devices you need to buy. Then looking for options, reviews, reports, or going to conferences as you try to get as much context as possible. Figuring out safety and security regulations. Listening to cobots more than once. But just like when buying a car, you will end up taking a risk.
This blog post won’t provide a definite guide for adopting AMRs. How could it? The market is constantly changing and everyone’s needs and goals are different. Standards and regulations are domain-specific. So instead we wanted to focus on what you shouldn’t miss; the structure of AMR. By understanding the main components you will be able to understand the most important requirements and points of discussion with your AMR vendors.
The autonomous mobile robots market
As more and more small and medium-sized companies are adopting automation, we see a shift towards more flexible robotics solutions. Even though these solutions certainly have different business and manufacturing processes as well as various types of infrastructure and resources, the needs are usually the same:
- higher production rates and increased productivity
- more efficient use of materials
- better product quality
- reduced factory lead times.
Traditional automation tools have been optimized by AI and IIoT enabling this shift, addressing customer demand for uniqueness and personalization, and through process innovation. This is categorized as advanced robotics, and it’s here where we find autonomous mobile robots. In 2021, the market value of conventional robots used in manufacturing is expected to reach almost 15 billion U.S. dollars, while the value of advanced robotics should reach some 3.7 billion U.S. dollars.
STIQ identified 231 AMR robotics vendors, but the market is highly fragmented, and that number is actually much higher. It’s worth mentioning that this includes companies of different sizes, developing solutions for highly specific use cases in non-sterile environments.
Autonomous mobile robots architecture
Autonomous mobile robots products are complex devices that combine hardware, software and specialized components. Devices are normally categorized by their navigation skills; localization, navigation and motion planning. Ultimately this defines their autonomy. But there’s much more behind AMRs. Navigation is just a functionality. So it’s important to know the architecture.
Choosing the right hardware
What are the main physical elements in an AMR? Wheels, encoders, brakes, motors, batteries and sensors.
There are many vendors for these hardware parts, and normally AMR companies do not produce these components themselves. Be clear on what you need here, and choose according to the exact functionality, environmental specifications and safety requirements required by your solution.
Check payloads, top speeds, terrains, battery life and so on. This information is widely available when you go to an AMR vendor. Check and compare. And if you want to dig deeper, think like a roboticist. Here’s a list of helpful links to help you decide between one element/component/architecture over another.
Learn about the right wheels for robots.
Learn about the encoders.
Learn and compare different types of motors.
Learn about batteries and performance.
Functional software of autonomous mobile robots
In this category, we put together all the software components that allow a robot to complete a functionality. Let’s say that you are looking for a robot to receive some material from a conveyor belt and bring it to a designated area. The functional software will include the scanning and visual processing, so the robot knows that it has reached the designated area and the end of the belt. It will also include the way the robot should receive and deliver the material and the ability for you to control and manage the device, or devices.
Obviously, software components will also include the localization, navigation, and motion planning. This is the heart of the AMR; it enables the robot to know where it is and move along a prescribed path safely. It could run a simple line follower algorithm that will require you to set up a painted line on the floor. Or it could have complete freedom, mapping the environment and avoiding obstacles. This part will also include designing the interactions with people.
For all of this to take place, the robot should be equipped with different sensors; from expensive lidar, to cheap IR sensors. Cameras, accelerometer, laser, ultrasound and other sensors will also be used for navigation and more.
Ultimately, navigation is a key differentiator for AMR. It also has an impact on the cost of the device. But like any other functional software it could be made by the AMR manufacturer or a third party.
So how should you choose these components? The main requirement for you and your vendor to address your needs is to start by clearly identifying your process to automate and what you can do to support the AMR. Is the robot going to work with other people? Can we have designated areas for the AMR? Can we augment the environment so that the robot finds it easier to locate its position? (e.g. using QR codes) Do we need to manage a fleet? These are some of the questions you should ask yourself.
Next, you need to build a list of requirements followed by a list of what needs to be done in your process to adopt AMR. Either way, we recommend taking into account the possibility for expansion, adaptation and customization right from the start. Functional AMR is the heart of the robot. Having the basic elements is key and knowing that your solution will be able to grow with you, adopt new applications, third party software or your own code, is what will give you room to grow. If this is important for you, then look for functional software that supports multiple applications (through libraries and APIs).
Finally, don’t forget to request your manufacturer to tell you upfront for how long they will maintain the functional software. As a customer, you should know for how long you will be receiving security updates, as well as the process the company follows to identify and patch vulnerabilities. The same effort you put into keeping your servers, or computers in your organization secure should be applied to any electronic equipment you’re buying. They should also adhere to your cybersecurity frameworks.
Operational software of autonomous mobile robots
Like any other device in your industry, AMRs need to be integrated into the ecosystem. Plants and warehouses contain robot fleets that need to be told what to do at any given time. What’s more, marching orders may change due to evolving needs and the optimal way to execute the task may alter based on changing environmental conditions.
Take for instance fleet management or navigation applications that are part of the functional category. They require communication, local or central decision-making capabilities, and interfaces to other systems such as safety cameras, safety cages, doors, elevators, etc. They also need to convey information such as status, location, health and more to the humans in charge of them.
AMR needs to have the tools to be integrated into your system. Otherwise, you will not use or take out the most functional software of your robot. It could also mean that you will need to purchase system integrators for those gaps. There are several options out there and currently, this is somehow standard.
Other operational software includes the tools used to deploy robots in a specific site by the automation integrator, monitoring tools, software version control, and more. Therefore, understanding the process also includes understanding the connectivity and telemetry needed between your new AMR and your existing infrastructure.
Operating systems of autonomous mobile robots
Operational and functional components will live on top of an operating system. The applications might be packaged in different containers (e.g.; snaps, docker) but they will all surely need to sit on top of an operating system.
If a company is deploying its own operating system (building a new distribution from scratch or customising an existing distribution using Yocto or Buildroot) it may drift from the distribution they were built upon to the point of incompatibility. Device manufacturers choosing this approach may find themselves with an operating system so heavily customised, they have to maintain it on their own effort over the long term. As previously mentioned, this comes at a significant cost in both human resources and infrastructure.
As a consequence, you need to be sure that the AMR manufacturer has proper documentation and a process for maintaining a fully-fledged operating system. The manufacturer also needs to provide evidence that they are putting in the time and engineering skills to maintain it. This also includes the security maintenance of the operating system as well as identifying and patching vulnerabilities.
Remember: the same security requirements you put in place for your computers in the network should be reflected in your AMR and its OS.
Automation is not a straightforward process. It requires significant planning and a deep understanding of your processes. This blog takes you through the main components of autonomous mobile robots intending to highlight their functionality, and what you should look for. From hardware to software, from functionality to operation, AMR is just more than navigation algorithms.
If you are building AMRs, learn more about OS security in our whitepaper: key considerations when choosing a robot’s operating system
Or explore how we have helped companies deploying robotics solutions reducing their OPEX in our case studies.