User Journey Mapping is a powerful tool for defining product scope and ensuring a seamless user experience. In this post we explore how it helped refine the arculus Fleet Manager, from identifying user needs to structuring functionality. By leveraging insights from previous versions, market feedback, and internal collaboration, we built a strong foundation for future development. This article is part of a series on creating value through strong product management—written by Georg Held, Product Manager in the Software Team at arculus.
Why We Turned to a User Journey Map
When the idea of revamping the arculus Fleet Manager came up, we quickly realised that a strong focus on all aspects of product development was essential to building a valuable product. In this context, finding the right product value was a key point of the debate. Additionally, we realised that there isn’t a single typical user of a Fleet Management System for Autonomous Mobile Robots (AMRs). Conversations with insiders of our legacy software revealed a wide range of expectations on top of the technical challenges of defining the product’s underlying architecture.
As we described in our previous post about product discovery, thoroughly analysing and defining the product's scope, users, and relevant operational workflows would be crucial before starting development. However, we also encountered many opinions on what to tackle first. Therefore setting focus and priorities without sacrificing oversight became essential. Let’s dive into how user journey mapping helped us rapidly advance with defining the scope and prioritising it.
What is a User Journey Map?
The goal of a user journey map is to gain a complete understanding of how users interact with the product throughout its defined stages. More precisely, it provides valuable insights into users' needs, expectations, and pain points—all essential for understanding users’ experiences and analysing operational workflows.
A user journey map is typically represented in a graphical map that provides an overview and supports collaboration between stakeholders
Visualising the entire user flow reveals gaps in the user experience and offers opportunities for innovation. Lastly, it helps us identify all development teams required for specific steps in the process, leading to the distribution of ownership across product development later on. User Journey Mapping is a prerequisite for identifying and designing a seamless product user experience, or in this case a system.
The User Journey Map for the arculus Fleet Manager
To get started, we broke down the project process in which the software is typically used:
End-of-line testing within the arculus AMR production
Project planning in pre-sales
Specification phase after customer quote acceptance
System and field commissioning
Operations, service & support
In each of these phases we structured the following:
User
Scope
Objectives
Interaction with the system
This quickly filled a large whiteboard, but also revealed the need for improvements and gaps in user details, especially in how they interact with the system. Through relentless user interviews, the full picture emerged. Below is a simplified version of our initial user journey map:
Since we already had great insights from previous versions of the arculus Fleet Manager and the market, we could quickly map the required functionality and the existing pain points. These shaped our first priorities, which we then refined further. Wireframes and prototypes helped validate hypotheses, leading to better concepts for users to achieve their goals at each step of the process (more on this in the next post). This resulted in many cards highlighting the specific functionality required.
As a last step, we further broke down the functionality by assigning it to the most relevant product development teams. This added structure and clarified ownership.
Learn more about the development of the arculus Fleet Manager here.
Conclusions and What’s Next?
In general the user journey map is a great tool for understanding users, their goals and operational tasks. It helped us define the product scope and, more importantly, prioritise the key things for an MVP (Minimum Viable Product) of the system. It also guided us in achieving a great user experience.
Finally, the tool itself—we used Miro—allowed us to collaborate efficiently. Based on the feedback we received, we highly recommend user journey mapping for the intralogistics industry. Now and in the future, this framework will remain a living tool for developing new products. It is also the basis for breaking down product ideas by applying user story mapping in each team's backlog.
In the next blog post we will explain the strength of having a well-aligned user journey in getting started with prototyping; precisely with extracting wireframes to collect first user feedback.
This post is a part of our Product Management Best Practices series. Stay tuned for more articles coming soon!
Autonomous Mobile Robots (AMRs), like our arculees, rely on several advanced technologies. Two key components are NVIDIA’s Orin NX and Debian OS (Ubuntu), a Linux-based operating system known for its stability and flexibility. Together, the two provide prime computing power and reliability to run our robots smoothly and safely. Hassan Saeed, DevOps Engineer at arculus explains how this combination supports our arculees and why it’s the ideal setup for our development.
Better Robotics with NVIDIA’s Orin NX
The arculees, our Autonomous Mobile Robots (AMRs), improve warehouse productivity, especially through their smooth navigation and modern safety features. However, to navigate safely and efficiently, our robots must process their surroundings in real time. This includes identifying obstacles, recognising markers, and making fast decisions. This requires strong hardware capable of handling complex data on the go.
This is where NVIDIA’s Orin NX, a compact System on Chip (SoC), comes in. Hassan Saeed, our DevOps Engineer, describes it as “a powerful board with sophisticated data processing capacity, along with advanced CPU and GPU capabilities.” By rapidly computing information from the robot’s software and input devices, Orin NX improves obstacle avoidance and marker recognition, allowing arculees to navigate seamlessly. Its GPU further optimises AI-driven tasks through efficient parallel processing, making complex computations faster and more reliable.
NVIDIA’s Orin NX Board
Debian - the Classic Operating System
Debian is a free, Linux-based, open-source system known for its stability, security and flexibility. These features make it an ideal choice for robotics, where a dependable operating system adaptable to various hardware configurations is essential for smooth functioning. Hassan expands on the multiple benefits of this strong OS:
"Debian provides a strong foundation for various software applications and supports a wide range of hardware. For example, you might have used Ubuntu on your computers. It is also a derivative of Debian with a user interface (UI) similar to Windows. Yet, Debian’s popularity stems from its security and robust package management system, making it a preferred choice for many developers and enterprises."
Debian is one of the oldest operating systems, offering stability and flexibility to users
Orin NX and Debian: a Powerful Combination
By combining Debian’s stability and flexibility with Orin NX’s real-time processing and energy efficiency, Hassan and his team created a system that ensures smooth navigation, real-time decision-making, and long-term adaptability for arculees. He delves deep into how they made the two technologies work together to achieve an optimal ecosystem at arculus:
FlexibilityandStability: Debian is a natural fit for the Orin NX hardware because it is flexible and stable. Its broad hardware support ensures smooth integration with the Orin NX, while its robust architecture makes the robot’s system more reliable.
Simplifying Updates and Adaptations: Pairing Debian with Orin NX streamlines the software update process for arculus. Integration with Debian’s package management system makes rolling out updates and security patches efficient. The regular support from Debian and NVIDIA ensures the software remains secure, up-to-date, and adaptable.
A Rich Ecosystem and Strong Community: Debian’s extensive software ecosystem and activity community provide a solid foundation for innovation. It supports various robotics applications and ensures continuous development and troubleshooting resources, which are invaluable for development cycles at arculus.
Seamless Integration for Core Functionality: Debian's strong support for robotics software aligns perfectly with Orin NX’s high-performance hardware capabilities. This integration enables arculus to deliver advanced robotics functionalities such as smooth navigation, obstacle avoidance, and precise task execution with reliability and security.
Finally, while this combination of two technologies already greatly serves the arculees, Orin NX offers various AI features that are especially relevant to robotics. Hassan and his team are actively exploring its Machine Learning (ML) aspects, such as predictive analytics, decision-making, data-driven processing, and computer vision. The aim is to utilise these features to further improve our AMRs and software.
Hassan busy working on his station at the arculus office in Munich
Integration challenges and how arculus solved them
Implementing NVIDIA’s Orin NX in the arculus ecosystem meant facing specific challenges. One of the main caveats, in this case, was the hardware incompatibility. Hassan explains, “NVIDIA’s kernel is designed to work with its own hardware, so it failed to recognise arculus’ custom-built board — the Robot Control Unit (RCU).”
The RCU, also known as the arculee’s heart, has multiple peripherals and devices that control the robot’s movements. So, to fully garner the benefits of Orin NX without compromising the functionalities of the custom-built board, the team had to make some adjustments.
“We configured all the devices according to the kernel provided by NVIDIA and also tweaked its device tree to ensure that the RCU’s components were fully supported,” continues Hassan, “It took some adjustments, but in the end, we integrated Orin NX smoothly and made the system work perfectly.”
The arculus RCU and NVIDIA’s Orin NX together at work
Three Cheers to arculus, Debian, and Orin NX
Choosing Debian and NVIDIA’s Orin NX for product development wasn’t just about compatibility. It was a strategic decision based on performance and practicality. Hassan Saeed, DevOps Engineer, explains what motivated the team:
“Debian’s popularity and extensive package repository made it an obvious choice for us. Its flexibility in supporting multiple programming languages, including C and Python, aligns perfectly with arculus’ software and development needs.”
At the same time, Orin NX stood out for its powerful hardware features, which are necessary for robotics. With external memory options, NVMe device integration, high CPU and RAM capacity, and advanced GPU capabilities, it provided the performance arculus needed. Hassan adds:
“Ultimately, the compatibility between Debian and Orin NX helped us optimise both software and hardware, ensuring efficiency in our operations at arculus.”
Product management in intralogistics has long been project-driven, often prioritising execution over long-term scalability. But to build better software products, a shift towards Product Discovery is essential. In this blog post, we explore why this approach matters, the challenges of moving from custom-built solutions to a structured discovery process, and how it has helped us improve our product roadmap and decision-making. This post kicks off a series on creating value through strong product management—written by Georg Held, Product Manager in the Software Team at arculus.
The Shift Toward Product Discovery
In the past, people often considered one of the product manager’s primary responsibilities as gathering requirements and engineering. While this is undeniably true, Marty Cagan brought more focus to it by introducing the term "discovery" in 2007. He described it as finding out what to build. In fact, he emphasised that finding the right solutions is harder than building them (see The Origin of Product Discovery | Silicon Valley Product Group).
And this is precisely what we at arculus have observed in software: in intralogistics, there is too much focus on execution. In an industry where a few experts design highly complex and customised systems, understanding the real problems of the market is difficult. In the past, project-based implementation addressed specific, individual challenges. Today however, speed, efficiency, and adaptability demand more than just custom solutions. Established product management with a stronger focus on market needs is essential to scale your business, serve a broader range of customers, and keep costs down.
Info: This article kicks off a series of posts on creating value through a strong product management focus. Stay tuned!
What is Product Discovery?
Because we draw from many different sources to define product scope, product discovery provides a strong framework for avoiding misguided development. Through continuous discovery, we test ideas against market problems, user needs, and business goals. Cycles of exploration, experimentation, and validation ensure the focus remains on promising concepts that users will appreciate. Therefore, the focus of product discovery is on “What”.
(Image generated by Gemini AI)
In future posts, we will explore these cycles further, for example, by using prototypes to assess user needs. Naturally this process isn’t always straightforward, as it lacks predictability. Regular decision points foster collaboration on how to move forward with an idea, helping to navigate uncertainty.
Ultimately it’s crucial to avoid wasting time on ineffective concepts. That’s why speed plays a key role in the early stages of exploration. Reducing effort on unviable ideas is essential, especially since teams should focus on delivering real value.
This is where product discovery comes in. It helps ensure teams move fast in the right direction and continue to innovate. For more details on addressing risks upfront, solving problems collaboratively, and focusing on outcomes (customer and business problems) vs. outputs (features), see Discovery vs. Documentation | Silicon Valley Product Group.
Product Discovery at arculus
At arculus, we describe product discovery as capturing market problems and finding specific user needs for our system. To capture these problems, we focus on:
Industry & market pain points through trend reports, competitive analysis and insider insights;
Customer requirements through early opportunity scanning;
User experience along the product journey through target user interviews and end-to-end testing;
Technical trends and the management of legacy architecture and technology.
All of these contribute as "insights", which lead to what we call a product idea. To develop these further, a team of product and technical experts explores solutions to the problems. Importantly we always keep the end user in mind. This enables a vertical perspective—crucial for the arculus system—which integrates both software and hardware. Too often we’ve seen these treated as entirely separate due to their technical nature, even though true functionality depends on seamless integration across all layers, from user interaction to underlying hardware.
The team creates concepts for an idea and supports them with whiteboard sketches or even clickable prototypes where useful. We then plan product increments to determine overall priorities. Based on this, we either opt out or continue planning and development. At this stage, our product departments have found what Marty Cagan calls the "right product”. In addition, there is a high level of transparency and collaboration among all stakeholders, a prerequisite for good, high-performing teams.
The Product Discovery and Delivery processes
We use Jira Product Discovery to facilitate this process, leading to the arculus product roadmap. Although any other tool could also work, this one provides the flexibility needed to orchestrate all items efficiently and transparently. Nevertheless, the arculus product team has found that rigorous discipline is more important than perfect tools.
Lastly, once a product discovery is done, the necessary product increment (PI) planning will bring the idea to the Development teams. If you want to know more about the delivery at arculus (“How”), read our previous post about fast development here.
Dealing with Project Requirements
As mentioned earlier, product teams dealing with many intralogistics projects often encounter various individual customer requests. While this is usually the norm, timing these requests is critical for any product manager. Additionally, handling requirements on a deal-by-deal basis leads to uncoordinated concepts.
As arculus grew, this became a real challenge and prevented us from consistently delivering a marketable solution. In fact our teams were delivering projects but had little time to follow a sustainable product roadmap. As a result the product architecture and business case suffered, leading us to plan a new version of arculus Fleet Manager (read more about it here).
This was not only a technical decision but also a shift towards excellence in what we build. By applying product discovery as described above, we broke new ground in addressing individual needs. Some of the best practices we implemented are outlined below:
Collaboration with the sales department(s): This allows the product team to understand potential product gaps in the pre-sales phase before an offer is made and provides enough lead time for thorough product discovery. While we may choose not to pursue some opportunities or fail to win them, the effort is worthwhile because it improves our overall understanding of the market.
Strict focus on the problem: This applies especially to customer requirements typically described as "one-liners" in a project's requirements catalogue. Among other things, this means evangelising the relevant departments so that customer interactions start with the problem rather than the solution. As Simon Sinek’s Golden Circle suggested, arculus teams relentlessly ask “Why” to identify problems.
Support project teams with product documentation and expertise: This helps the team understand the portfolio upfront and during specification negotiations with customers. This is also a potent tool for steering discussions toward existing features. We regularly learn that these features are both sufficient and appreciated.
The commercial team at arculus watching a presentation about new product features
Housekeeping in product discovery to identify risks early:
Process: We created a product discovery process to keep track of the product discovery backlog (currently over 150 ideas). This allows us to see the status of an idea throughout its evolution: from the initial stage (parking lot) through discovery, planning, and development. The development status is captured via links to the implementation item in each team’s backlog.
In addition, each idea has fields to identify affected teams, customers, and even relevant business goals. It also considers time factors, such as when ideas should reach a product release and other milestones, ensuring that the roadmap reflects these priorities.
Using the arculus product discovery template, we have structured the way we capture ideas to make them easily understandable for anyone.
Responding to all product ideas is typically challenging. That is why the recommendations above, along with strategic direction, e.g., in focus markets, help us make the right decisions. As a result, we constantly update the product roadmap. This also gives all product management stakeholders confidence in what the team delivers. In the end we are positive that we made the right decisions to make our customers happy.
Conclusions and What is Next?
By applying a thorough product discovery approach to product management, arculus has already taken huge steps toward building better software solutions. We gained coordination, structure, speed, and oversight in creating the roadmap. This led to making more informed decisions and as a result, a better product-market fit.
As product discovery is a constant process, it is important to keep evolving and improving it. Among other factors, increasing the product value remains a key focus. Hence, we constantly evaluate performance by using available data points and feedback circles to keep prioritising the right product ideas, ultimately creating value in the market. This will bring arculus' Product Management team closer to the famous “The Ultimate Guide of a Product Manager Day by-Day Activity” by Lucas Balbino.
Stay tuned for the next post of our Product Management Best Practices series!
Labour shortages, high productivity demands, and ever-changing markets are reshaping the supply chain industry. To stay competitive, companies must understand and adopt the technologies and strategies defining warehousing in 2025. This blog post highlights the top five intralogistics trends to help you address industry challenges and transform your business this year.
Technological advancements, market analysis, and industry research define the best practices to improve intralogistics. From streamlining processes to full-scale automation, warehouse solutions have improved tremendously in the last few years. Yet, shifting markets, workforce shortages, and rising productivity demands leave room for innovation. As technology evolves, new trends emerge to address these challenges. Let’s explore the key intralogistics trends for 2025 to help your business stay ahead this year.
Top 5 Trends in Intralogistics for 2025
1. Warehouse Automation
Labour shortages continue to challenge the intralogistics industry while rising demand for faster deliveries pressures businesses to boost productivity. To address this issue, many companies have turned to warehouse automation, streamlining operations and improving efficiency.
With so much to offer, it is no wonder mobile robots will remain in demand. Their market size is thus expected to reach USD 29.86 billion in 2025.
3. Artificial Intelligence (AI)
Artificial intelligence (AI) and machine learning (ML) are no longer just buzzwords; they are transforming intralogistics by enhancing efficiency and accuracy. These technologies enable real-time inventory management, optimise storage solutions, and streamline order fulfilment processes.
For example, AI-driven predictive analytics allow better equipment maintenance, alleviating breakdowns and operational costs. Similarly, it offers accurate demand forecasts, ensuring better resource allocation and reduced overall expenditures. It is safe to say that integrating AI and ML in warehouses will remain an emerging trend in 2025.
4. Internet of Things (IoT) and Real-time Monitoring
Another trend to improve supply chain efficiency is the Internet of Things (IoT). This field involves interconnected devices, software, and other technologies with sensors and processing abilities that connect and communicate over the internet.
IoT enables real-time monitoring of warehouses, allowing for immediate data collection and analysis, streamlining intralogistics, improving management, and enhancing decision-making. Companies should harness this potential to increase efficiency, optimise processes, and meet market demands.
Team arculus learns how easy it is to operate arculees, our AMRs
To comply, companies are increasingly adopting green logistics practices, such as utilising electric vehicles. Another key focus is obtaining certifications to accurately report CO₂ emissions, an essential prerequisite for meeting these new standards. These efforts align with the growing consumer demand for eco-friendly products and services. The hope is to make the future green!
Looking Ahead
The intralogistics industry is here to grow, with technology driving faster, more efficient solutions. Innovations in robotics, data analytics, machine learning, AI, and automation are transforming warehouses. Don't let these trends pass you by—integrate them into your supply chain processes to keep your business flourishing in the future.
Autonomous Mobile Robots (AMRs) can locate and navigate themselves in an environment—this is how they accomplish their tasks of assembly and transportation. But how do they know where they are and where they need to be? Behind these simple questions lies the science of localisation, mapping, and navigation. This blog post explains how our AMRs, the arculees, locate, map, and navigate to ensure accurate, efficient, and autonomous movement.
Autonomous Mobile Robots (AMRs), like the arculees, must navigate different environments, such as warehouses or other facilities, to move from one place to another and perform a task. The first step to navigation is mapping, which simply refers to the process of creating a map. Before arculees can drive autonomously, we need a map because otherwise, we don't have a point of reference; we don’t know where the robot is and where it needs to go.
LiDAR Scanners: They use laser beams to measure distances to objects, generating a point cloud that is used to create a map using the robot’s software.
Inertial Measurement Unit (IMU): The IMU is an electronic device that provides data on a robot’s acceleration and rotation.
Wheel Odometry: It is the process of using data from wheel encoders to estimate the robot's position and orientation over time by calculating how far the wheels have travelled, typically relative to the robot's starting point.
Together, these tools help the arculees create a map representative of their real environment and determine their position within it.
Our developers at work to ensure the arculees navigate accurately
SLAM - Simultaneous Localisation and Mapping
The method of collecting data from scanners, IMU, and wheel odometry to generate a map is called SLAM. It stands for simultaneous localisation and mapping. To create an accurate map, you also need to know where the robot is on that map, which is what localisation stands for in the acronym. With the scanners and sensors in place, you drive the robot around and collect the scanner data and the data on where the robot is. Finally, you combine that to create a map.
Once the map is there, the robot software loads the map as a reference frame and is then able to drive within it. Since the map itself has a coordinate system, the software can tell the robot where it should move and where it is, creating a route and driving from A to B.
Tools and Techniques: Mapping, Localisation, and Navigation
Localisation, mapping, and navigation are the processes that go hand in hand to ensure autonomous driving of mobile robots like the arculees. However, there are certain tools and techniques to make the processes work:
At arculus, our tools, algorithms and sensors include the SLAM toolbox, Google’s Cartographer, IMU, wheel odometry, and two laser scanners. The SLAM toolbox is an open-source 2D SLAM tool specifically developed for Robot Operating System 2 (ROS2). Both Cartographer and SLAM tools are used for real-time localising and mapping across multiple sensor configurations and platforms.
Map of our office generated with Cartographer and LiDAR scanners
Meanwhile, there are two ways to record a map:
Offline: We create a recording by driving around the environment whose map we need and collect data. This data includes scanner information, IMU (inertial measurement unit) readings, and wheel odometry. Afterwards, we process the recording using a Cartographer to generate an offline map.
Online: We primarily use Cartographer for online recording. It simply processes live data from the robot in real time to create the map.
Once the arculees have a laser map, they can drive automatically. However, to complete tasks, operate safely, and avoid deadlocks, an efficient traffic management system overlooks the robots, giving them specific driving orders. This system lives in our fleet manager. The best path is calculated by considering various aspects such as battery charge, distance, and possible driveways where the robots can go. Therefore, our Fleet Management Software sends step-by-step instructions to the AMR, guiding it for the next actions at a time. As the robot moves, the fleet manager continuously updates the route, ensuring safe, smooth, and accurate navigation.
The Fleet Management Software tells the robot which route to take
Current Challenges and Hopes
Like any other technological advancement, AMR mapping and navigation comes with challenges, but there are always ways to find better, more viable solutions. While our current mapping techniques work perfectly within small to medium areas, a possible caveat can be creating maps of large and dynamic environments. However, our team of developers at arculus addresses this by recording the data and later processing it offline on more powerful computers, where computational constraints are no longer a concern.
Although the present mapping processes are effective, arculus aims to improve and innovate continuously. That is why our ultimate goal is to keep updating and refining the AMR mapping methods.
Hopes for the Future
Future advancements in mapping and navigation promise faster algorithms and higher map accuracy. Improvements in accuracy can address persistent issues. For example, enhanced precision would enable robots to navigate more efficiently, reducing errors and the need for manual corrections.
These advancements hold great potential for the role of autonomous mobile robots. With greater accuracy, robots could move faster and operate even more reliably. As a result, accuracy can create a more stable and efficient solution for dynamic environments.
The Way Forward
Mapping and navigation in autonomously driven vehicles is an emerging but crucial part of robotics. As such, it has ample room for growth and advancement. While there is no silver bullet to improve everything all at once, the tools developers use for mapping and navigation are composed of smaller components and algorithms, so a slight improvement in one of the parts can positively affect the entire process. On the other hand, staying connected to recent and relevant research, reading publications and keeping oneself up-to-date on what’s happening in the field is essential for future breakthroughs. There is much room for improvement, and tools need updating, especially with artificial intelligence entering the equation.
Autonomous Mobile Robots (AMRs) can significantly enhance warehouse productivity. However, selecting the right robot for your specific intralogistics needs is essential to get the most out of this innovative technology. In this blog post, we’ll share key tips to help you choose the right AMR for your warehouse.
As e-commerce continues to grow and labour shortages persist, many industries are turning to warehouse automation to stay competitive and keep up with the increasing demand. Autonomous Mobile Robots (AMRs) are a popular solution, capable of reducing shipping time by 30% to 50% while also improving safety, scalability, flexibility, and cost-efficiency. However, not all AMRs are the same, and finding the right one depends on your specific warehouse requirements. Let’s explore the various factors to consider when selecting the best AMR for your operations.
How to Choose the Right AMR for Your Warehouse
1. Know your Operational Needs
The first step is to consider which tasks the robot will handle in the warehouse. These operations could range from transporting and sorting products to assisting with assembly workflow. The AMR you choose should be based on these specific needs. For example, while agile AMRs like arculees are a great option for underload carrier and pallet transportation, other mobile robots such as Automated Guided Vehicles (AGVs) are more suitable for vertical lifting.
Warehouse operational needs play a key role in choosing the right AMR
2. Check the Pay Load Capacity
Load capacity is another major factor when choosing an AMR. The type of materials a warehouse handles will determine whether a robot with a lower or higher load capacity is more suitable. For instance, for moving lighter items, like textiles or consumer goods, an AMR with a lower payload capacity will work best. On the other hand, a robot designed to carry high loads is a better option for transporting heavier machine parts. Matching the AMR’s payload to the product weight is crucial for ensuring smooth operations.
3. Analyse the Cost
Budgeting is an essential step when investing in a new technology, but the lowest upfront cost doesn’t always guarantee the best value. Beyond the initial price, it’s crucial to factor in expenses like maintenance, integration, software updates, and energy usage. For instance, AMRs that seem cheaper at first may demand frequent servicing or complex integrations, driving up long-term costs. Balancing these factors will help you ensure a more cost-effective investment for your business.
4. Prioritise Safety
Integrating AMRs into warehouses involves regular interaction between robots and humans in shared spaces, making safety a critical concern. To minimise risks and maintain a hazard-free environment, it's essential to choose robots that comply with safety standards like TÜV SÜD and DIN protocols. This ensures both secure and efficient intralogistics operations.
5. Look for a Scalable and Adaptable Robot
Successful integration of AMRs also depends on their flexibility. As industries evolve and warehouse needs change, robots that can adapt to new environments, navigate obstacles using sensors, and respond to real-time data are highly desirable. The good news is that being easily programable and able to accommodate fluctuating workloads, AMRs are generally scalable. When purchasing an AMR fleet, it's important to prioritise flexibility in their operations.
Different Mobile Robots serve different purposes in warehouses
6. Find a Supportive Vendor
Finally, choosing the right service provider for successful AMR integration goes a long way. When selecting a vendor, consider your specific warehouse needs and look for a partner that offers comprehensive solutions. For fully automated warehouses, a provider like Jungheinrich can supply a wide range of technologies, from AMRs to Automated Guided Vehicles (AGVs) and forklifts, ensuring seamless integration.
In Short
Integrating Autonomous Mobile Robots (AMRs) in the supply chain facilities is an effective option to support the workforce and tackle the ever-increasing demands of manufacturing. However, for maximum benefit, industries must opt for autonomous robots that are best suited to their need. To achieve that goal, companies must understand their operational requirements, research product specifications, analyse the cost-benefit ratio, and then choose the right AMR to make their warehousing processes safe, efficient, and optimal.
At arculus, innovation and efficiency are the most critical factors when devising solutions. This commitment is adhered to at every stage of our Autonomous Mobile Robots (AMRs) production cycle—from prototyping and defining the different processes, to building, scaling, and testing them. In this blog post, Thorsten Mersdorf our Production Manager explains how his team produces the arculee M, our latest AMR model.
Recently, arculus introduced our latest Autonomous Mobile Robot (AMR), arculee M, to the world of intralogistics. Based on extensive market research and valuable customer feedback, the new model stands out for its enhanced load capacity, wide use case capability, good manoeuvrability in narrow aisles, and ease of maintenance. Our systematic yet innovative production processes have been pivotal in successfully delivering our state-of-the-art AMR.
AMR Production at arculus
AMR production means procuring and assembling the required components to build a functional and safe robot, ready for delivery and deployment. This crucial stage in AMR manufacturing plays a vital role in ensuring an efficient and streamlined product.
Exploring the arculee M production journey can thus offer valuable insights into making robot assembly more efficient. Thorsten Mersdorf, our Production Manager, emphasises that the AMR production processes fall into the following four categories:
Knowing the Product: The first stage involves being 100% clear about the AMR and understanding the required specifications through researching the market, studying previous versions of the robot, and using any insights gained for prototyping.
Defining the Processes: The next step is organising the data and ensuring that all the instructions at every step are clear for effective robot assembly.
Securing the Resources: Defining and integrating adequate tools for various purposes and building a motivated team to carry out the task.
Assembling and Adapting the Product: Finally, the team assembles, calibrates, and tests the robot. Moreover, flexibility, improving processes, and making changes according to market and customer needs and feedback are also essential for efficient AMR operation.
Cross-team collaboration
To support these practices, the Production department works closely with the Development teams at arculus to improve our AMRs. This collaboration is another secret ingredient behind our fast and efficient introduction of the arculee M. According to Thorsten, “Efficient production starts with the development of the products.” For example, developing separate modules for different robot components allows easy assembly and maintenance of the arculee M, by offering more flexibility and scaling options. That is just one way a decision at the development stage can affect and improve the building stage.
Thorsten Mersdorf (right) working together with Thomas Fuhrmann (left), a Software Engineer from the Brain Team
In addition to learning about the target product and coordinating with other departments, a lot more goes into the production cycle of the arculees. Let’s find out how to build a robot with mastery.
How to Build an AMR
The AMR production involves several key stages:
1. Pre Assemble
The actual process begins in Dresden, home to the arculus warehouse. Here, the team carefully thinks through the material selection beforehand. For example, we rely on corrosion-protected steel for the arculee M's structural components, ensuring durability and strength.
Leveraging an innovative modular approach, the arculee M comprises separate modules for different components, with dedicated teams putting each one together. This strategy allows for the pre-assembly of modules independently from the main construction, providing remarkable flexibility. It facilitates scaling and allows for outsourcing before the final assembly.
Thorsten further explains, “First of all there are the key modules. For example, the Electronics Module focuses mainly on the Robot Control Unit (RCU), also known as the robot's heart. Others include the Active and Passive Lift Module, the Drive Module, and the Chassis. Lastly we have the Auxillary Modules that cover all functional parts, such as cameras, key switches, access points to the robot, and all the UI features and environmental detection sensors.”
2. Assemble it All
The main assembly follows the fishbone principle, using cause-and-effect diagrams (resembling a fishbone structure) to create an optimal concept. Once that’s in place, the team installs each pre-assembled module into the robot. Of course, it is not simple, and the team considers several factors for aligning and securing the mechanical parts of the AMR. These include ensuring the tolerance of each part, optimising the fitting process, getting the specifications right, and maintaining strict quality control throughout the supply chain.
Federica Granato and Thorsten Mersdorf working on the assembly of an AMR in the production area
3. Integrate the Robot
Configuring and calibrating different components and software is also crucial for the robot's proper functionality. At this stage, the team integrates the motors and sensors into the robot via the RCU and the S7 Safety process. Effective implementation of safety features in the AMR is critical for on-site equipment and personnel protection. Other tasks covered during the integration stage include:
Software flashing: Depending on the needs, it may include updating, resetting or rebooting the robot software for smooth operation.
Scanner, camera, and sensor adjustments: Calibrating the cameras, scanners, and sensors is crucial to ensure that AMRs collect accurate data about their surroundings for efficient object detection and navigation.
Robot lift system and drive configuration: Fine-tuning these systems ensures the AMRs can move and position themselves seamlessly at the customer facility.
4. Test
Testing involves checking the system, application, and performance to ensure safety and functionality. The team uses the four-eyes principle, meaning at least two people evaluate each process to guarantee accuracy. For this, we have quality checks throughout the production process. We also conduct other evaluations, such as the system test on the bench and the robot’s endurance test. The idea is to confirm that the AMR is functional according to the quality requirements and follows the safety standards.
The entire process of assembling, integrating, and testing a robot takes around 10 hours. However, the estimate doesn’t include the time spent defining the concepts and processes, or arranging the modules.
5. Have a Cool Team
A group of people who are passionate about what they do is one measure of the success of any project. The production journey of an AMR, like that of arculee M is no different. As Thorsten explains:
“Teamwork is also extremely important in production. If we don’t align the team towards a goal, we won’t be able to harness the skills of each individual in the best possible way. As a result, we’ll fail to awaken the required ‘winning spirit.’ But if we create the right environment, teamwork can develop, and the members will trust each other and ultimately enjoy taking on challenges and solving problems.”
Thorsten takes pride in the squad - a group of highly talented, driven, and creative individuals:
Jonas Jaeger is the Team Lead for Assembly and Integration and manages teams, resources, and the production area in general.
Federica Granato and Anika Lorenz, the Production Engineers, are responsible for quality assurance for the arculees and the warehouse management.
Josef Bauer and Marcel Trouillaud are the Mechatronic Experts. They cover integration and end-of-line processes.
Tamas Szipli is the Production Expert. He handles key resource assembly, tooling, and planning.
Diego Hidalgo, Integration Expert in Mobile Robotics, tackles tasks related to software and the robot UI.
Konstantin Bikard and Stefan Klein, the Production Technicians, take care of the assembly and equipment setup and adjustments for safe, high-quality robots.
Fazli Senel is the Robotics Service Engineer. He tests and maintains the AMRs for efficient robot operation.
“If you take a closer look at production and its environment,” continues Thorsten, “teamwork is one of the main factors contributing to smooth processes and good product quality.”
A part of the Production Team (from left to right): Marcel Trouillaud, Jonas Jaeger, Thorsten Mersdorf, Josef Bauer, and Tamas Szipli
6. Have the Right Tools to Hand
The other crucial resource for efficiently building agile robots is the tools. When it comes to specific equipment, Thorsten mentions various items for different stages of AMR production:
For organisation: To effectively structure and manage tasks and processes, we use different software such as operations1, Assemblio, and Jira.
For assembling: Depending on the task, the team may use various tools. Usually, these include assembly tables, cranes, and torque screwdrivers.
For calibration and testing: We have equipment and calibration benches for post-assembly configuration and software packages to optimise the performance of the AMRs. We also use the self-developed Robot UI for several End-of-Line (EoL) processes to ensure the proper functionality of the AMRs.
Some of the many tools at the AMR production site of the arculus office
7. Have an Awesome AMR - the arculee M
Once the arculee M is built and functional, it is ready to transport materials in warehouses, supporting the automation of the intralogistics industry. The most impressive specs of the arculee M include:
If you want to adopt the arculee M as a solution in your facility, please visit Jungheinrich for more information.
The arculee M in the testing area of the new arculus office
In short, arculus with its continuous commitment to innovation, assembles and integrates the arculee M as an efficient Autonomous Mobile Robot for intralogistics. To sustain this success, it's essential to remain agile and responsive to the ever-changing technological advancements and dynamic demands of the intralogistics industry. By continually adapting, evolving, and optimising our processes, Thorsten’s team turns these challenges into opportunities, advancing our production standards and contributing to the ongoing advancements in the field.
When developing a new Autonomous Mobile Robot (AMR) for intralogistics, deriving key lessons from the real-world use cases from the very beginning of the journey is crucial. This is what arculus did with arculee M development. In this blog post, Carlo Fitz, our Managing Director; Romano Wolf, our Product Lead for Robotics; and Iuri Ferreira, our Release Coordinator, discuss the what and how of the development process.
New AMR for Efficient Intralogistics: Goals and Strategy
Let's start with the basics. What was the goal and the development strategy for the arculee M?
Carlo: We have been part of the Jungheinrich since 2021. We began this partnership with our first Autonomous Mobile Robot (AMR), the arculee S. Since then, we have gained extensive field experience with the arculee S. We received valuable feedback from Jungheinrich's sales organisation and product and portfolio management. Based on this feedback, we developed a new product increment: the arculee M.
Romano: At the beginning of our partnership, we analysed Jungheinrich's installed base of pallet transport systems. This analysis focused on developing the arculee M specifically for pallet transportation. By examining this extensive database of installed projects, we gained valuable insights into the necessary criteria for various use cases, such as dimensions, load capacities, and other specifications.
With this information, we could precisely tailor the arculee M to meet the needs of our addressable market from Jungheinrich's perspective. This allowed us to identify the optimal specifications for our new robot and address gaps that arculee S could not fill. As a result, we expanded our market share and met the customer needs even better than before. This was our primary goal from the beginning of the development.
Can you introduce the arculee M as a system? Please explain how it's designed to play a key role in intralogistics applications.
Romano: We need to understand the arculee M as a system from two perspectives. On the one hand, there is robotics, which includes peripherals like stations and backpacks necessary for pallet transportation. On the other hand, we have fleet management, which is essential for integrating with warehouse management systems, also known as host systems. For this, we utilise a software layer from Jungheinrich, the logistics interface, which acts as an abstraction layer for our fleet management. Thus, the arculee M system encompasses all robotics components, the fleet management and the logistics interface.
Carlo: From the customer’s perspective, you get transportation from point A to point B, where the robot performs the physical tasks. However, when replacing manual transportation with automation, it's important to consider various customer interfaces. The host system manages these interfaces, determining where transportation is needed. This makes the arculee M part of a larger system with numerous software components.
What are some common pain points in intralogistics that the arculee M aims to solve? Can you give examples of how it tackles these issues?
Carlo: Logistics is a cost factor but also a crucial enabler. While transporting goods from A to B doesn't seem to add much value, having them in the right place at the right time is essential. This is where the arculee M comes in. This new AMR enables efficient transportation while minimising costs. It performs reliably 24/7, making it an effective substitute for a cost-intensive intralogistics system.
Moreover, transportation systems like conveyors were very reliable and fast in the past. However, they were also inflexible. Changing the configuration, such as the source or sink, was costly and required disassembly, reassembly, and significant infrastructure adjustments. The arculee M system, on the other hand, offers much greater flexibility. The initial setup for a project can evolve without incurring high costs.
Romano: There are several reasons why our customers want to automate. One major reason is cost. Over time, they aim to amortise their investments in optimisation, achieve scaling effects, and become more cost-effective. While cost was the primary driver in the past, recent changes in the labour market have shifted priorities. Nowadays, labour is hard to find. So many customers are driven to automate because they cannot secure the necessary workforce for manual tasks. Companies must invest in optimisation to maintain their business operations and remain productive.
Iuri, Release Coordinator at arculus, is busy working with the arculee M in the testing area
The arculee M Use Cases
What are the primary use cases for which the arculee M was developed?
Iuri: The arculee M tries to improve the solutions for underload carrier transport, meaning the arculee M would drive underneath the load, lift it, and carry it around in a plant. Its primary focus is the intralogistics, transporting goods from people to storage. This includes use cases such as narrow aisles with highly stacked items, in conjunction with other automation solutions that Jungheinrich also provides, to move goods around in parallel efficiently.
Romano: The arculee M is specifically designed for pallet transportation, particularly for Very Narrow Aisle (VNA) applications. These are high-rack storage solutions, and Jungheinrich is already a major player. We saw a significant opportunity to improve pallets' transport into these high-rack storage solutions.
One key advantage is our ability to connect two automated trucks from Jungheinrich and arculus, deploying them as a single, integrated system. However, this is just one example. Overall, the arculee M focuses on pallet transportation and can be used in various settings, such as warehouses and production facilities, where pallets must be moved from one location to another. The system efficiently picks up and shuffles pallets at designated stations.
How flexible is the new robot for specific client needs and requirements?
Carlo: The core idea was to balance these two ports. We created a physical platform with the arculee M, incorporating all the essential, complex functionalities such as localisation, navigation, and lifting activities. Based on this platform, we developed a backpack system that allows different backpacks for different load carrier types and makes the system flexible for various applications.
Additionally, we redesigned the software layer to focus on easy deployment and system robustness. This included creating a layout that minimises the number of robots used, increases throughput, and minimises deadlocks.
Romano: When we look at the market, we see a huge variety of pallets and other load carriers, and from the beginning, we aimed to stay flexible. So, how could we ensure this? We didn't want to develop a different product for every load carrier type. The idea behind the arculee M was to keep all the robotic complexity within the platform and the robot itself. Then, we created a mechanical and electrical interface for the backpack, which can be customised for different load carriers.
Iuri: This approach allows our software to remain mostly standard and basic, making testing and ensuring robustness and performance easier. At the same time, it provides the customer with the flexibility to customise the backpacks as needed, supported by the logistics interface.
The Development
Let's talk development. How are technical specifications and performance benchmarks determined for a new robot?
Iuri: When developing a new robot, the first step is to examine the market. We identify the market points we want to cover and define our target use case accordingly. We then analyse the market competition. With this information, we evaluate our technology stack to determine how we can leverage our existing capabilities to meet our use case requirements and what modifications are necessary. Navigating these modifications presents an interesting challenge. The more changes we introduce, the more complexity and risk we add to the development process, and the harder it becomes to meet deadlines.
At the end of the day, our goal is to create a high-performance robot that maximises throughput for the customer. So, there's always a fine line between further increasing robustness and stability while minimising risks and bringing a good product to market.
Romano: We call what Iuri just mentioned the platform approach. Our strategy involves developing products vertically, meaning we have access to all platform components ranging from the high-level software layer to the low-level software running on a dedicated microcontroller.
When we develop a new derivative, we first examine the use cases to identify relevant requirements and product specifications. Based on these insights, we can adapt and scale our platform as needed. This might involve adding peripherals or sensors or modifying the physical aspects of the platform. These changes could be in mechanics, electronics, or software.
The key advantage of this approach is that it is always based on our existing platform and expertise. This allows us to efficiently scale our platform to meet the new use case we want to target.
Carlo: The goal is to create a minimum viable product (MVP) with specific features that can be brought to market quickly. This will allow us to gather customer feedback and understand the market demands. From there, we will iterate on the product, refining it based on real-world data.
Initial ideas for a product are based on hypotheses. It's crucial to test these hypotheses early in the process to validate or correct our assumptions. This helps us determine if our initial market hypotheses are accurate. Through this iterative approach, we can evolve the MVP into a final product that effectively meets market needs.
The Evolution from S to M
Finally, let's talk about evolution. How does the arculee M signify an evolution from the arculee S regarding functionality and benefits?
Romano: For the arculee S, we initially targeted table transportation. At that time, we had major projects in warehouse applications, and transporting tables from point A to point B was a common task. This was the primary purpose of the arculee S. However, after Jungheinrich's acquisition, we discovered the field of pallet transportation. Our first project in pallet transportation was done using the arculee S, and it was successful.
However, despite this success, we encountered limitations as we brought the product to market, particularly in scaling up load capacity and height. When reviewing potential new projects, we noticed a gap in our portfolio—we couldn't handle higher load requirements. This realisation led to the development of the arculee M. It was designed to close this gap and accommodate higher load capacities and greater load heights, addressing the limitations of the arculee S for the pallet use case.
Iuri: The improvements don't stop there. As we discussed earlier, robotics is a dynamic, evolving field. Based on field feedback, we significantly improved the robot's serviceability. We focused on how easy it is to provide service and maintenance. The robot includes several critical safety features that must be tested annually. With this in mind, we made changes to simplify the service process for technicians, ultimately reducing costs and enhancing the overall product.
Romano: Specifically for the arculee M, we divided the product into several submodules, such as the lift, active lift, passive lift, electronics module, and peripherals. This modular approach makes the robot easier to assemble, significantly reducing production time. Additionally, it simplifies maintenance, making it easier to access, service, and replace components. Achieving these goals has been a significant success for us.
Due to its optimal performance, the arculus Robot Control Unit (RCU) was retained from arculee S into the arculee M.
How has field experience from the arculee S shaped the development of the M model?
Carlo: The arculee M inherited many core ideas from the S. For example, we retained the central Robot Control Unit (RCU) in the arculee M, which we developed for the S. The RCU is a closed electronics unit that incorporates all the key electronic features needed to create the robot's autonomy layer. However, for the improvements, in addition to focusing on load capacities, we concentrated on enhancing localisation and navigation capabilities, putting significant effort into software development in these areas for the new robot.
Romano: Looking at the arculee S and its components, we learned from field experience which components worked well and which posed challenges due to supplier issues or performance. We applied these lessons to the arculee M. We kept or adapted the components that performed well while we upgraded components where we have seen potential for improvements. This included enhancements to actuators, sensors, and software.
This is all about how focusing on particular use cases improved the development of the arculee M. Watch the complete interview below!
In this blog post, meet Linus Ferlinz, Product Owner, and Fabian Na, Senior Mechanical Design Engineer at arculus, as they discuss the mechanics of our latest Autonomous Mobile Robot (AMR), arculee M, focusing on its versatility with different backpacks and stations.
The Functionalities: Backpacks, Stations, and the arculee M Mechanics
What are the different types of backpacks and stations currently available, and how do their functionalities differ?
Linus: The reason for having backpacks is to facilitate a variety of use cases. For example, our customers have pallets. Depending on the use case and the factory layout, you can transport pallets lengthwise as well as crosswise. Now, backpacks allow us to adapt a robot for different tasks without needing another variant of the robot. We can do that just by adding another backpack on top.
How does the arculee M's mechanical design ensure compatibility with various backpacks?
Fabian: The mechanical design is, in a way, a universal interface between the base product and the backpacks. So, we have the same mounting positions and electronic interface for all the backpacks. As a result, the base product of the arculee M never needs to change, and all the backpacks are compatible.
How does mechanical design ensure durability and ease of maintenance, especially considering the environments the robot will operate?
Fabian: We understand that our Autonomous Mobile Robots (AMRs) are used in highly industrial environments where durability and safety are crucial due to the possibility of workplace hazards. Additionally, we prioritise serviceability and maintenance by ensuring service technicians can access all components without needing extra tools, facilitating efficient field maintenance.
Fabian Na, Senior Mechanical Design Engineer at arculus, discusses the various aspects of the arculee M mechanics
Integration between the Backpacks, Stations, and the arculee M
What are some key considerations in ensuring seamless integration between the robot, its backpack and the stations?
Linus: One of the strengths of arculus is our close-knit working environment. So we have the production in the same building as the software and hardware development. As a result, we constantly interact in the office, even on breaks, such as in the kitchen and at the coffee machine. This facilitates collaboration. Moreover, we discuss topics and progress during our biweekly sprint reviews, ensuring feedback for different departments. Finally, at the same time, on the team level, we have daily alignments on topics we're working on to ensure that we all work in the same direction and have the same focus.
Fabian: So it's not like segregated departments work in their own directions. Instead, we're all working together on the product as the final goal. And I think that's something special that arculus does.
The Creation Process
What does the design and development process for a new product typically involve?
Fabian: The process starts with the conceptualisation phase. We base it on the product requirements and try to meet the functionalities with any concept possible. Once we have a couple of concepts, we typically do some sort of decision matrix to determine our best way forward, and then we go into a detailed design process. Of course, we're keeping the product's functional requirements and technical specifications in mind during this whole time. That's how we make sure that the product works.
How do you ensure that new products meet both technical specifications and user needs during the development process?
Linus: A very important point here is that we are all involved in testing our products. So, we have a testing area in the building, and everybody, including the developers working on the mechanical design, can go there and test their product - This is the very first step. For example, when we have a proof of concept or a prototype, we can test it and see how it feels and works. Then, in the next stage, we have pilot phases in our internal factories at Jungheinrich, where we can get customer feedback before we roll out to external customers.
Fabian: Additionally, the technical specifications we define for our new products typically come from the use case and user needs. So we really try to focus on, for example, what performance our customers need to stay competitive. Such requirements are then translated into the technical specifications for the product.
Linus: Another critical point is our use of short, iterative cycles during development. We can quickly adjust our approach if something isn't working as planned. This flexibility allows us to change direction whenever necessary, ensuring we stay on the right track.
Testing a product at different stages of development is crucial for improving the mechanical design
Were there any specific components or systems that required extensive testing or redesign?
Linus: We recently had this one situation when we changed the navigation method, a significant change for many of our products. We collaborated very closely with our software team to align on the visual detection of, for example, our handover stations. The solution included iterating our station design, significantly impacting the overall products.
Was there a point where you had to balance mechanical complexity with functionality or cost? How did you navigate this?
Fabian: I would say that mechanical complexity results from balancing functionality and cost. So, as a mechanical design engineer or any type of engineer, when you're designing something, there are three main factors:
Cost
Time
Quality
Depending on which of those three factors is the priority for the project will determine how complex the system will have to be. So, the day-to-day work that we do includes trying to balance and manage these three factors of how we can design something cheap but also, let's say, complex enough to achieve the functionality that we require.
Linus: You might also need to consider the product's stage. For example, at a very early stage, you just want proof of concept. Maybe costs are not the highest priority at this stage. Once you have checked that it's working how you want it to, you can move on to the next stage and optimise it for costs.
Can you discuss the process of creating custom-designed backpacks for specific customer's needs?
Linus: So we get those inquiries from the customers. Our first step is to ensure we have all the necessary data. This includes understanding the layout of their sites to verify all accessible driveways. Once we have this data, we can either redesign the load carriers or obtain CAD (Computer Aided Design) models from the customer. We then check if our existing portfolio can accommodate these load carriers. It's always good if the company doesn’t have too many different components because keeping the parts inventory manageable is crucial. However, we will create a customised design for the specific load carrier if our existing options are insufficient.
Linus, Product Owner at arculus, explains that the mechanical complexity decisions differ depending on the AMR’s development stage
How does each of you view the most impactful functional improvements in the arculee M compared to the arculee S?
Linus: I think the most important feature of the arculee M is its increased load capacity of 1.3 tons. Despite this higher capacity, it maintains the footprint of a standard pallet, making it ideal for carrying industrial pallets. Additionally, the new AMR offers greater compatibility with load carriers, allowing it to transport pallets both lengthwise and crosswise, a capability not available in the arculee S. This focus on pallet transportation makes the arculee M truly versatile.
Fabian: We have made significant strides in the design of the arculee M, focusing on assembly, serviceability, and design simplification. These improvements ensure that the product is durable and long-lasting. Additionally, this new AMR is easier to maintain. Overall, we've enhanced general performance to guarantee that arculee M will remain reliable in the field for an extended period.
The Functionalities of the arculee M
Can you discuss a specific functionality that you personally worked on or found challenging?
Fabian: There are a lot of complex assemblies inside the product. One of the challenges is to find a solution that can withstand the forces and the dynamic conditions that the product will be experiencing in the field. So it's, for example, the lifting system. It's not simply lifting something up and down; we must reinforce the system by breaking centrifugal forces when driving in curves. We have made some very big strides in the design of how we provide this robustness to our product.
How did your approaches differ during development?
Fabian: During the development process, we worked closely together. We focused on meeting the requirements, like ensuring the AMR can lift and travel fast enough. But we weren't, or at least, I wasn't so far in depth with how we’re transporting load carriers and the whole backpack floor station aspect of it.
This is all about backpacks, stations, and the arculee M mechanics. Watch the entire interview below!
The electronics of Autonomous Mobile Robots (AMRs) play a key role in determining their functionality and efficiency. The same goes for arculees, our AMRs. Join Tobias Schwering, Andres Magallanes, and Jolly Jacob from the arculus electronics team as they explain how the arculee M, our latest product, builds on the electronics strengths of its predecessor, the arculee S, but also offers several advanced features.
The Evolution of Electronics: From arculee S to arculee M
Can you describe the evolution of the electronics aspects from the arculee S to the arculee M? What were the key improvements or changes made?
Tobias: One of the main goals for the arculee M was to ensure fast development. To achieve this, we reused as many components from the arculee S as possible, thereby accelerating the process. We identified key parts that could be reused, starting with the RCU (Robot Control Unit).
The RCU, initially designed for the arculee S, was adapted for the arculee M with some additional functionalities to support new use cases. For instance, we incorporated a safety concept for ramps. We have not designed the S to navigate ramps, but the arculee M can go up to 10-degrees on the ramps. So, this was a big thing. Besides adding these few interfaces, we made general improvements to the RCU. However, for Andres, the harness presented different challenges.
The arculus RCU®, designed for arculee S was also adapted for the arculee M
Andres: The harness plays an important role in the mechanical and electrical design of a robot. There was a major change here from the arculee S to the M. In the S, we used a single long harness, which, if you put it on the table and extend it, will probably be three meters long. In contrast, the arculee M features a more modular approach. The modular approach means splitting the harness into different modules. Therefore, we easily replace, handle, and manufacture them, simplifying the assembly process during production.
However, the harness differs not only in modularity but also because of the new components it supports. We have introduced different devices, such as upgraded scanners and new data communication interfaces, marking a substantial evolution from the arculee S.
Tobias: Perhaps we should clarify that when we mention "scanner," we refer to the safety laser scanner. This type of scanner ensures our robot can operate safely around humans, making it functionally safe. Additionally, we use the safety laser scanner for navigation purposes.
Jolly: Another aspect to consider is the design. We had already tested many RCU modules with the arculee S and found them efficient and high-performing. Therefore, we retained these modules in the arculee M without compromising efficiency or performance. We took the proven modules from the arculee S, integrated them into the new RCU, and made necessary modifications to suit the new robot.
The harness wire spools at the electronics labs
The Technical Aspects of the arculee M Electronics
What are some of the most significant technical innovations in the electronics of the arculee M?
Jolly: The camera used in the arculee M would be an innovative technology, and the brake control board, with its sensing method, would be a technological advancement, too.
Tobias: We updated our safety scanner system to provide more precise laser data. This enhancement improves the entire software stack, leading to better localisation, system navigation, and more robust performance.
Jolly: Another important change, though not a major technical one, is the modification of the LED light. Previously, it was pretty large and used a lot of space. We have now significantly reduced its size to less than half, making it more efficient and directing the light precisely where needed.
Andres: In this new project, we took a different approach to designing the harness using computer-aided design (CAD). Previously, we would create a prototype harness for the robot, document the length, estimate wire coupling lengths, and then compile a bill of materials based on what we used or had available.
While we had electrical documentation specifying the connection procesdures, we lacked detailed documentation on how to build the harness. Now, with the CAD approach, we have integrated the harness design into the 3D design of the entire Autonomous Guided Vehicle (AGV). This method is easier for manufacturers to maintain and handle, allowing for the direct creation of production drawings.
Jolly: The new approach allows us to easily remove parts for testing or modification with the arculee M. We had not implemented this method in the arculee S. It’s a valuable addition that we can use in all scenarios, including testing during production and maintenance.
Tobias: It was mainly designed for production so that we could pre-assemble modules. That was the main idea, I think. But then we realised that it also has several other advantages. So now you can just exchange parts. For example, if something breaks in the field, we can just ship one part there and exchange it.
Andres: Now, we are more interested in making it easier to produce, assemble, and maintain and repair on the field. So, if one reset button is not working, we can just remove the panel, replace it with a new one, and then investigate what the problem is with this button.
Tobias: Well, a robot is just such a complex thing. So we call it always the integration phase - the first time a robot is built, and then we put everything together. And there were tests upfront. But your tests are never complete until you have a complete robot. The completion of this, with every single robot that I saw, usually would take a long time. However, with our modular approach with the arculee M, more people could work on it in parallel, which sped up this process.
After all, that's one of the key points where speed and efficiency in development are required.
Andres and Jolly are busy working in the arculus electronics lab
How have power management and efficiency been improved in the new electronics setup?
Tobias: The biggest addition was the deep sleep feature, which allows the robot to reduce its power consumption to extremely low on a remote command. Also, the robot can restart itself — it all comes from the fleet manager!
Except for that, I think the power consumption and efficiency were already pretty great in arculee S, and arculee M is now also relatively efficient. We have our completely self-designed inverter system, which is very power efficient.
Jolly: One improvement is to speed up the lift timing. So we just increase the speed of the lift, and in that way, we save some operation timing. Also, we just changed some circuitry with proper DC converters, ensuring more efficiency. Initially, we had designed for more power, but we don't require it with arculee M. So, we redesigned those sections to save some power.
Tobias: The arculee M weighs nearly twice as much as the arculee S. It can lift more, and move around more with less power consumption.
The Challenges of the arculee M Electronics
What were some of the biggest challenges faced in developing the new robot, and how did you overcome them?
Tobias: One of the biggest challenges was the time frame. We wanted to develop arculee M very quickly. However, we had to make changes to the RCU, including adding new interfaces. For example, we introduced a new front camera and 3D camera system, which required an additional Ethernet interface on the RCU.
We had to push out a new revision of the main board fast. Since it’s a large PCB (Printed Circuit Board), we had to order, assemble, test everything on schedule before starting real integration. So, fitting this into the development cycle while ensuring enough time for proper testing was a significant challenge.
Andres: Also, this braking board is a very interesting system because, according to the current, you can detect the opening and closing of the brake. The industry already uses this principle, but not so widely. And yeah, implementing it here was a new experience overall.
Jolly: We quickly assembled our new PCB for the brakes and other components, tested it, and debugged everything to ensure it worked as expected. The tight timeframe was, thus, one of the challenges we faced, requiring us to keep working at full speed.
Tobias: But overall, we did three revisions, and had to add only one connection. Over these two revisions, we added two resistors. Besides, we have now built a technology base that we can use in the future, for example, for electronics module development.
Tobias explains the importance of functional safety when making design and electronics decisions for an AMR
Integration of Mechanics with arculee M Electronics
How do the robot's mechanics and electronics integrate to enhance performance and reliability in the new model?
Andres: Well, I think the harness makes a great example. Moving from a big, fully integrated harness to a modular approach required us to work with the mechanics department. Of course, the design initially comes from the electronics, which places all the components you need there, estimating wires, cross-sections, cables, and all the signals that need to go. But as I mentioned before, it's now fully integrated into our robot's CAD system, which is where the mechanics enter the picture.
Tobias: The modular approach made achieving electromagnetic compatibility (EMC) more challenging. We must adhere to some limits regarding how much a robot can radiate. Of course, we've managed to do it with the arculee S - we have passed the official certification in an accredited lab. But with arculee M, everything was larger, and there were more connectors where the wires were pulled apart for easy access and more interconnections in the single parts. So, it's not one single structure that works as a shield anymore. This meant collaborating with the mechanics department to develop a system that fulfilled the modular approach's requirements without ruining the robot's EMC capabilities.
Jolly: There were some other areas where electromechanical integration was necessary. For example, if we had to place a PCB in a different part of the robot for lighting, we needed to fix a position for that. The mechanics team would help place it at a proper angle and in a certain way. Similarly, mounting the battery was also where the electromechanical integration was crucial.
The arculee M Electronics: Lesson Learned
Let's talk about the lessons learned. What lessons learned from the development and the deployment of the arculee S were applied to the new model's electronics?
Andres: One thing we have learned while developing arculee S was that if you want to be fast with the design, you need to parallelise the work with other teams. You cannot block the next team's work; it will never work, and we implemented parallel working for the arculee M.
Tobias: But it goes both ways because we also learnt what strategies and components used in the S were really good ideas. For example, the drive system and our self-developed inverters turned out to be more or less one-to-one usable in the arculee M. So, of course, there were lessons about things that were not so well with the S, but also about what worked and can be used as it is in the next robot.
Andres: We just changed some parameters because we used different motors with different physical characteristics, but that was all!
Tobias: Yeah, but only for lifting. The drive motors we used for the arculee M only have a stronger brake. The rest is the same. So, that was only for the ramp. As we discussed, the arculee M is heavier, can carry more, and can stay on ramps. So, it has to be stable and shouldn't start moving them. This is why we had to beef up these electromechanical brakes a bit. However, that was not in the scope of the arculee S.
Moreover, we added the brake controller board, a supervision feature. The idea was to ensure the brakes are actually were stronger and working before we introduced them to the driving into ramps! Otherwise, that might be dangerous. Since functional safety is a major topic in many design decisions, including electronics and AMRs work in close collaboration with humans, we must ensure that nobody gets hurt working with a robot.
The spacious testing area at the new arculus’ office
Jolly: Also, we tested this with an actual load, not in a simulation. So we put the real load on and applied the brake while moving. Then, we performed all the tests immediately to ensure everything was working perfectly.
Tobias: Moreover, our basement room at the old office wasn't large enough for the brake test. You know, to bring the robot with a weight of 1.75 tons - actually, we even tested with overload, so 2.05 tons, to full speed and then brake. But we managed to find suitable test halls then, thanks to Jungheinrich, our mother company.
However, with the new office, one of our biggest concerns was how much the floor could take. Thankfully, we have access to a great testing area now!
This is all about the arculee M electronics. Watch the entire interview below!
