How We Designed AGV-Based Intralogistics for a Multi-Floor Electronics Workshop

In this multi-floor electronics workshop intelligent logistics project, we needed to design an automated material-handling system covering raw-material delivery, line-side logistics, finished-goods transfer, buffer areas, elevators, and warehouse handoff points.

The project operated on a two-shift schedule with approximately 20.66 effective production hours per day. Material flows crossed multiple floors and production areas and involved several different pickup and drop-off interfaces.

In a workshop logistics automation project like this, choosing an AGV or autonomous forklift is usually not the hardest part.

The more difficult questions are:

Which material flows should be automated, how many vehicles are required, which routes should they use, where should pickup and drop-off points be located, how should vehicles move between floors, and can the existing production equipment reliably interface with unmanned vehicles?

For this reason, we could not simply replace the existing manually operated transport vehicles with AGVs. We first needed to re-evaluate the entire intralogistics network.

This article focuses on why we designed the system this way, rather than repeating the equipment configuration and workflow already shown in the case study.

We First Converted Daily Logistics Volume into Data We Could Actually Design Around

The raw data customers can usually provide includes:

• how many products are produced each day;
• how many deliveries are made each day;
• how much raw material enters the workshop each day;
• how many finished goods need to be moved out each day.

These figures help us understand the overall logistics scale, but they are not enough to determine how many AGVs are required.

For an AGV system, the more important question is:

How many transport tasks must be completed per unit of time?

This project used a two-shift operating schedule. Each shift lasted 12 hours, but after deducting breaks and other non-production time, the effective operating time was about 10.33 hours per shift, or approximately 20.66 hours per day.

We therefore converted the customer's daily transport volume into hourly logistics demand and used that as the basis for vehicle quantity, route planning, and equipment-capacity calculations.

That conversion matters.

Suppose 200 transport tasks must be completed every day. Knowing only 200 trips/day does not tell us how many AGVs are needed.

Those 200 tasks could be concentrated into eight hours or spread across 20 hours. Production lines may also issue material requests in concentrated periods rather than at a perfectly even rate.

What really determines fleet capacity is:

Trips per Hour + Travel Distance + Loading/Unloading Time + Waiting Time

So instead of configuring vehicles directly from the number of trips per day, we first put production time and logistics tasks onto the same time scale.

We Did Not Treat Raw-Material and Finished-Goods Logistics as the Same Type of Task

Although both raw materials and finished goods are ultimately transported by unmanned vehicles, the operating logic of the two flows is different.

The primary objective of raw-material logistics is:

Make sure the required material is already in the right place when the production line needs it.

The primary objective of finished-goods logistics is:

Release the production line and temporary storage area in time, and move completed products to the next logistics node or warehouse.

In this project, the raw-material flow needed to connect:

Raw-Material Warehouse → Preparation Area → Buffer Area → Line-Side Preparation Area → Production Line

Finished-goods logistics involved production completion, pallet or carrier preparation, destination confirmation, vehicle pickup, elevator transfer, and final warehouse handoff.

For this reason, we could not simply design one generic 'AGV route.' We had to analyze the two logistics flows separately, including:

• when raw materials needed to arrive;
• where materials should be buffered in advance;
• how the production line should issue replenishment requests;
• when finished goods were allowed to leave the line;
• whether finished-goods transport needed to use an elevator;
• whether the receiving warehouse was ready to accept the load;
• whether upstream or downstream waiting time would tie up vehicles.

Only after separating the different task types could we determine which routes could be shared and which tasks required different vehicle types.

Why We Could Not Simply Reuse the Existing Manual Logistics Routes

A route that works for a manually driven forklift is not necessarily suitable for an unmanned vehicle.

A human driver can see an obstacle, temporarily steer around it, or adjust the vehicle position based on the situation. An AGV needs a more stable and standardized operating environment.

During route evaluation for this project, we found that some main aisles needed to be widened by approximately 30 cm. Pickup points, line-off points, the connection to the insertion workshop, and elevator interfaces also needed to be re-evaluated.

AGV route design therefore does not mean:

Copy the route used by today's manual forklifts onto a digital map.

Instead, we need to re-check:

• effective aisle width;
• turning space;
• passing zones;
• pedestrian-vehicle crossing points;
• whether temporary materials may obstruct the route;
• whether sufficient waiting space exists in front of elevators;
• whether the vehicle can safely adjust its position for pickup and drop-off.

In some cases, changing the physical layout is more effective than trying to improve the navigation performance of the AGV.

If an aisle itself does not provide enough safety margin, higher positioning accuracy cannot solve the lack of physical traffic space.

Why We Needed Different Types of Unmanned Material-Handling Vehicles

This project was not a matter of choosing one AGV model and using it for every task.

We evaluated different unmanned vehicle forms, including Laser SLAM forklifts, lifting vehicles, and roller vehicles.

The reason was simple:

Different logistics interfaces require different pickup and drop-off methods.

If the load is palletized and the vehicle must perform the fork pickup itself, an autonomous forklift is more suitable.

If the material must interface with a fixed workstation, buffer rack, or a transfer point at a specific height, a lifting vehicle may be more appropriate.

If the production equipment already uses roller-conveyor interfaces, a roller vehicle can transfer material directly between equipment without manual intervention.

Vehicle selection therefore cannot be based only on:

• Rated Load;
• Travel Speed;
• Navigation Accuracy.

It also depends on:

What happens at pickup and drop-off?

In other words, once the vehicle reaches the target location, how exactly does it take the load, and how does it hand the load over?

This often has a greater influence on vehicle type than the question of how the vehicle travels between two points.

Why We Had to Standardize Equipment Interfaces First

After reviewing the existing equipment, we identified another issue: the installed equipment had not been built around one standardized unmanned-logistics interface.

Different machines used different transfer directions. Some transferred loads from the wide side, others from the narrow side, and interface heights also varied across the site.

If AGVs were connected directly to all of these interfaces, the vehicles would have to adapt to multiple mechanical handoff standards.

That would increase control complexity and reduce long-term system stability.

We therefore required the interfaces to be standardized, including:

• a consistent conveyor transfer direction;
• a standardized docking surface;
• a primary docking height standardized at approximately 340 mm.

This reflects an important principle in workshop logistics automation:

Do not make the mobile robot adapt endlessly to a non-standard site. Standardize the site interface where practical.

The more standardized the interface, the simpler the vehicle movement can be.

The simpler the vehicle movement, the fewer abnormal conditions the system usually needs to manage.

Sometimes the most effective way to improve AGV reliability is not to add more sensors or more complicated software logic, but to make the mechanical interfaces between different pieces of equipment consistent.

Multi-Floor Logistics Made the Elevator Part of the Material-Handling System

The project involved multiple floors, and both raw-material and finished-goods transport needed to use elevators.

This meant the route was no longer simply:

Point A → Point B

A typical task could instead become:

Pickup → Elevator Waiting Area → Elevator → Destination Floor → Drop-off

At that point, the elevator was no longer just a building facility. It became a shared logistics resource.

For this type of route, we needed to consider:

• how the AGV requests the elevator;
• when the vehicle is allowed to enter after the elevator arrives;
• whether the elevator car has sufficient space for the vehicle;
• how the AGV exits on the destination floor;
• how multiple AGVs queue when they request the elevator at the same time;
• whether an elevator fault could block the logistics flow;
• whether a buffer area is required in front of the elevator.

If this waiting time is ignored and the transport cycle is calculated only from normal driving speed, actual system capacity can easily be overestimated.

In a multi-floor project:

Travel Time ≠ Driving Time

The real task cycle also includes:

Waiting + Docking + Elevator Transfer + Loading/Unloading

All of these time elements ultimately influence fleet size.

How We Determined the Required Number of AGVs

Vehicle quantity cannot be determined simply from the number of production lines.

One production line does not necessarily require one AGV, and several lines cannot necessarily share one vehicle efficiently at all times.

For this project, fleet sizing needed to consider:

• logistics tasks per hour;
• distance per task;
• pickup time;
• drop-off time;
• elevator waiting time;
• empty return travel;
• charging time;
• production peaks;
• multi-vehicle dispatching efficiency.

Vehicle demand was calculated separately for different logistics scopes.

For part of the raw-material and finished-goods flow, the project estimate indicated that approximately 8 vehicles could cover the required transport demand, with an expected reduction of about four conventional manual logistics positions.

For roller-vehicle logistics, the recommended configuration was 11 roller vehicles and 4 charging devices to support around-the-clock automated operation.

This shows that AGV quantity is not fundamentally a procurement question.

It should come from:

Material Flow → Task Frequency → Cycle Time → Vehicle Utilization → Fleet Size

Vehicle utilization should not be pushed as close to 100% as possible.

If a system is designed to run at nearly full vehicle utilization, one vehicle entering charge mode, waiting for an elevator, or encountering an abnormal condition can quickly remove the remaining throughput margin.

Fleet sizing therefore needs to leave room for normal variability and necessary non-transport time.

Why Buffer Positions Were Part of the AGV System

AGVs can automate transport, but they cannot eliminate takt-time differences between upstream and downstream equipment.

For example, a production line may have completed a batch before an AGV arrives.

Or an AGV may deliver raw material to a production area that is not yet ready to receive it.

Without buffer positions, the vehicle has to wait.

That reduces fleet utilization and may cause vehicles to occupy main aisles or equipment interfaces.

For this reason, the project considered not only vehicle routes, but also:

• Raw-Material Buffer;
• Preparation Area;
• Line-Side Buffer;
• Finished-Goods Waiting Area;
• Elevator Waiting Area.

These positions effectively decouple the two operating rhythms:

The production line can run according to production takt, while the AGVs operate according to logistics dispatching takt.

The two systems do not have to be perfectly synchronized at every material handoff.

In a complex workshop logistics system, buffer space is not necessarily wasted space.

Well-planned buffer positions can actually reduce vehicle waiting and improve overall system stability.

Why the Central Dispatching System Did More Than Decide Which Vehicle to Send

As the fleet grows and routes span multiple areas and floors, allowing each AGV to navigate independently is not enough.

The system architecture in this project connected ERP, MES, WMS, WCS, AGV Scheduling, RCS, and the central dispatching and equipment-execution layers.

The system needed to know more than:

Which vehicle is closest to the task?

It also needed to know:

• what material was waiting for transport;
• where the material was currently located;
• which production line was the destination;
• whether the destination position was available;
• whether the current route was available;
• whether the elevator was occupied by another task;
• which vehicles were charging;
• which vehicles had already been assigned other tasks;
• which buffer positions were already occupied.

So true intelligent logistics is not simply:

AGV autonomous navigation.

It is:

A system that continuously organizes logistics tasks according to production demand, material status, equipment status, and site traffic conditions.

The vehicles are only one part of the execution layer.

Why Wi-Fi, Floor Conditions, and Remote Maintenance Had to Be Confirmed Early

Selecting the AGVs and planning the routes did not mean the site was ready for deployment.

The project placed clear requirements on the operating environment.

For example, the floor needed to remain flat and clean, without significant damage, hollow areas, oil contamination, or adhesive residue. Slope and local flatness also had to remain within the specified limits.

The reason is straightforward.

Unmanned vehicles depend on stable wheel contact, sensor detection, and positioning.

A surface condition that feels like only a minor unevenness to a human driver may affect an unmanned vehicle's:

• positioning;
• fork pickup height;
• load stability;
• braking distance;
• long-term mechanical wear.

Wireless networking was another infrastructure requirement.

The vehicles need continuous communication with the dispatching system while moving, so the project also needed to consider:

• Workshop Wi-Fi Coverage;
• Access Point layout;
• Channel Planning;
• Roaming;
• Dead Zones;
• network stability.

The project also planned VPN and remote-access conditions for initial server-software deployment and later remote maintenance.

So in this project:

Floor + Network + Interface Standardization

were not secondary tasks to be handled after the AGVs arrived on site.

They were part of the infrastructure required for unmanned logistics to operate reliably.