At the core of every arculee, our Autonomous Mobile Robot (AMR) is its brain. This powerful software system processes sensor data, executes commands, and guides the robot through complex environments. Software Engineer Thomas Fuhrmann explains how it works and why it’s essential to the robot’s performance.
What is the arculee Brain?
The brain is the central software of an arculee that manages all the tasks of the robot, including navigation, decision-making, and command execution. It receives orders from an outside source, like a fleet manager, processes its surroundings through sensor data, decides movements, and ensures overall efficiency in AMR operations.
Thomas Fuhrmann, Software Engineer at arculus, uses the analogy of the human brain to clarify its functions:
"The arculee brain functions similarly to a human brain. If you imagine an arculee as a body, the chassis is like the physical form; the electronics and cable harnesses are the organs and blood vessels. Just like in humans, the brain controls everything for the robot."
Processing the environment
Thomas highlights three main steps the arculee brain follows when processing its surroundings:
Sensing: The arculee uses different sensors to gather information about its environment, similar to how humans rely on sight or hearing. For example, sensors like LiDAR generate detailed point clouds that map the robot’s surroundings.
Interpreting: The brain processes the sensor data to interpret the real world. For instance, it can locate itself and recognise objects and obstacles that might be present in the robot’s path.
Implementing: Based on the interpretation, the robot makes timely decisions, such as stopping or altering its route to avoid collision with an object in the way.
LiDAR sensors on one of the arculees
The Brain’s Tech Stack
Developers at arculus build the arculee brain entirely in-house and avoid relying on external frameworks to maintain full control over performance and system behaviour. Thomas explains that they use C++ for the core system because it provides the speed and low-level access required for efficient robotics. For user interface components, they use Python, which allows for faster development and more efficient testing.
To improve modularity and efficiency, the developers plan to migrate the stack to ROS2, a well-known robotics framework that enables clearer system architecture and easier integration of new components. We will explore this migration in a future blog post.
Thomas, working on the arculee brain code
Challenges and Solutions
Developing a sophisticated piece of technology like the arculee brain comes with its own set of challenges. Thomas points out the following three:
Code Maintenance: The brain stack, including the code base, has evolved over the years, becoming increasingly complex. As features and functionalities expanded, maintaining the code became more challenging due to increased interdependencies within the program and legacy structures. The team tackles this by constantly checking and conducting frequent debugging sessions.
Managing Complexity: Our AMRs navigate autonomously in dynamic environments. This requires a solid system that can handle a wide range of possible scenarios and corner cases for maximum efficiency, safety, and optimal performance.
Testing and Validation: The office testing area allows developers to test the arculees in a controlled environment to ensure quality before deployment. However, the robots don’t always behave as expected, especially during the early stages of development. To improve performance and stability, the team runs countless tests and refines the software based on real-world behaviour.
Testing real-world performance and function is crucial to developing the arculee brain
Sharper Brain, Stronger arculees
The arculee brain handles all the core functions of the robot and can thus make or break it. Thomas sees a well-designed brain as key to precision, reliability, and adaptability. As development continues, improvements in navigation and decision-making will help arculees respond more effectively to increasingly complex environments. A sharp brain doesn’t just keep an AMR moving—it sets the foundation for smarter automation.
Prototyping is essential in the development of software for intralogistics, allowing teams to test ideas, refine solutions, and enhance user experience before full implementation. In this article from our Product Management series, Georg Held, Product Manager at arculus, shares how we use prototyping to drive innovation, optimise software performance, and improve efficiency.
Prototyping in Intralogistics
Intralogistics systems, supporting warehousing and production require a well-integrated hardware-software solution. While many monolithic systems perform well, they often hinder innovation. Exploring, testing, and refining new ideas before implementation is challenging. To address this, arculus leverages prototyping to gain insights before adopting new solutions. This allows us to collect early feedback, minimise risk, and improve efficiency to maximise product potential.
Let’s explore how arculus uses prototyping to innovate in planning, installing and managing a fleet of Autonomous Mobile Robots (AMR).
What is Hardware-Software Prototyping?
Today's prototyping culture goes back to Eli Whitney's promotion of "interchangeable parts”. In the late 1800s he advocated standardising identical components for easy replacement. This enabled mass production, simplified repairs, and improved integration and testing of new parts. It also allowed cost-effective iterations to enhance products in development, or for already existing ones, forming the foundation for modern prototyping.
Centuries later in the 1990s, the term hardware-software co-design emerged, as embedded systems gained recognition. Today arculus builds on this concept with a strong prototyping culture. Hardware-software prototyping as the name suggests, combines both hardware and software, allowing users to test products before full production. This approach enables effective testing and fosters innovation, efficiency, and clarity. There are many ways to engage users:
Physical models, even non-functional ones, are used to represent form and design;
Mock-ups that demonstrate the visual design of a concept;
Simulators that replicate system behaviours;
Clickable prototypes that allow users to interact with the system.
Numerous benefits such as the early identification of user experience problems, justify the time and effort required to create and test prototypes. Feedback from these tests is critical for future product development iterations, and establishing a learning culture through prototype experimentation is essential. As discussed in the previous blog post, prototypes are a key part of product discovery at arculus.
The Strength of Prototyping at arculus
The high complexity of intralogistics systems requires a strong prototyping culture. At arculus we rely on it not only for hardware but also to guide product development. By incorporating prototypes early we gain valuable insights from the start, enabling continuous evaluation and necessary adjustments throughout our discovery process. This agility ensures we integrate feedback early on, optimising resources while refining user experience. Crucially, recognising when to stop prototyping after validating a hypothesis ensures efficiency and keeps product delivery on track.
From Wireframes to Clickable Prototypes
After agreeing on the user journey we immediately moved to wireframes of the desired functionality, adding brief descriptions for context. This created a collection of screens covering key parts of the user interface, while revealing gaps to address. Using a collaborative tool like Figma, we efficiently captured extensive feedback in real time, enabling continuous iteration.
Wireframes evolving to a clickable prototype using Figma
To better reflect the user experience, we compiled a clickable prototype by adding interactivity to the wireframes. This helped overcome challenges from our legacy software toolchain, as the previous solution lingered in people's minds. The visual, and more importantly the interactive approach, encouraged users to explore new solutions, helping them quickly adapt to move beyond past systems and actively engage. In the end, the validated prototype answered many of the questions that our development teams had, as they built the real application.
Understanding System Performance
Later on, and as an important part of the user journey for the arculus Fleet Manager, we simulated a fleet of mobile robots, to see the heart of the software in action without connecting to real vehicles. This framework helped us explore possible transport scenarios for the first version of the application. Using a challenging transport matrix, we configured a large-scale simulation scenario—another way of prototyping that allowed us to understand performance on all levels of the software at an early stage in the product discovery and development phase.
Using Mock-Ups to Test and Understand Software Performance
In this phase we validated the required infrastructure, architecture, and algorithms for the arculus Fleet Manager. We set up dozens of driveways, deployed 100 mock-up vehicles, and established 1000 handover stations. The simulation ran smoothly for hours, and the new software toolchain achieved the goal of having a stable foundation that optimised material flow in intralogistics for our customers.
The prototype proved that the core components of traffic management were suitable for large-scale deployment. However, for the MVP (Minimum Viable Product) we opted for a more robust, purpose-built simulator developed from scratch.
In one of our future blog posts, we will provide insights into the simulation capabilities of the arculus Fleet Manager.
Connecting the Dots: From Prototype to Physical Movement
The next step was connecting to real vehicles. Since the software on the robots already had defined interfaces and communication protocols, we could quickly perform the first driving actions. Naturally we recognised the need for a more robust interface between the arculus Fleet Manager and the vehicles for real projects, but taking a step-by-step approach reduced the complexity of software-hardware interaction early on.
Instead of defining and implementing the entire interface at once, we iteratively developed the most important functionalities for validation. One goal was to confirm that the new arculus Fleet Manager, with its high user experience standards, could guarantee safety and accuracy in real-world scenarios. For instance, through prototyping we tested the hypothesis that users wouldn’t need to enter error-prone coordinates, but could rely on a visual interface for the alignment of all layout objects. Benchmarking vehicle positions between the layout and reality took several iterations, but each step confirmed we were on the right track.
Hardware-Software Codesign and Prototyping in the arculus Test Area
The prototypical approach also helped us gain the trust of critical users, especially the field engineering teams responsible for commissioning projects at customer sites. Beyond validating the initial goals, prototyping also revealed other crucial improvements to the user journey. To capture those during typical testing sessions, we created systematic scripts with expected results, leading to clear actions for related teams. And half a day later the backlog already reflected new items for upcoming sprints. Rigorous prioritisation enabled teams to stay focused, and subsequent test sessions confirmed that development was moving in the right direction.
In an upcoming blog post, we will share more insights on how the arculus Fleet Manager’s user interface supports rapid project deployment.
Our Recommendation
There is no one-size-fits-all approach to prototyping. So here is our recommendation for getting the most out of it:
Select and agree on the component or feature to prototype. Often prototypes are not for the most technically complex topics, but for those requiring the right user experience. Focus on the hypothesis and goals you want to achieve and strictly adhere to them to complete concepts quickly.
Prioritise between low-fidelity and high-fidelity. Although prototypes support more efficient development, consider how much effort and complexity to invest. Low-fidelity prototypes, even on paper are often enough in the early stages of product development. Remember: the priority is to validate the concept, not how you build the prototype.
Discuss and choose the right prototyping tools. The most suitable tool depends on the type of feedback you need. Over the years we've learned not to limit ourselves to a few tools, but to embrace cutting-edge solutions, and to stay open to trying new ones. Also, don't feel obligated to reuse the same prototype for subsequent development stages.
Finally with the advent of generative Artificial Intelligence (AI), it has never been easier to start prototyping. AI not only aids in creating prototypes, but also in quickly analysing and evaluating feedback. As this technology evolves, we continue to explore innovative ways to prototype, accelerating our product development in the future.
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. 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.
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.
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!
