How We Designed Unmanned AGV Logistics for an Injection Molding Workshop

In this injection molding workshop unmanned logistics project, we needed to manage two continuous logistics flows moving in opposite directions:

Delivering empty blister trays to the production area

and

Removing full trays loaded with finished parts from the production area.

The project was located on the second floor of an injection molding workshop, where the logistics system needed to connect injection molding machines, line-side equipment, elevators, and surrounding logistics areas. Each carrier weighed up to approximately 5.81 kg and measured about 230 × 219 × 311 mm. We selected a roller AGV for automated line-side handoffs, and the vehicle was designed with four onboard buffer positions.

The real design question was therefore not:

Can an AGV move a tray from Point A to Point B?

It was:

How can empty-tray delivery, full-tray pickup, vehicle movement, equipment handoff, and production calls be combined into one continuously operating unmanned logistics system?

That became the starting point for the entire solution.

Why We First Separated Empty-Tray Delivery from Full-Material Pickup

At first glance, empty blister trays and full material trays may look like two loads handled by the same AGV.

From a production-logistics perspective, however, they represent two different requirements.

The objective of empty-tray delivery is:

Deliver an empty tray to the correct production location before the equipment needs it.

The objective of full-material pickup is:

Remove completed material from the line in time and free up line-side buffer space.

If empty trays do not arrive on time, production may run short of available carriers.

If full trays are not removed quickly enough, the production area may experience:

• line-side accumulation;
• insufficient buffer positions;
• temporary manual handling;
• equipment waiting;
• aisle obstruction.

For this reason, we could not create one generic:

Transport Task

Instead, we needed separate task logic for:

Empty-Tray Delivery

and

Full-Material Pickup

In the empty-tray flow, a request is initiated from the tray-arranging equipment at the production side. The central control system receives the call, creates the transport task, assigns a vehicle, plans the route, and then completes the final handoff through the roller interface.

For full-material pickup, the system receives a collection request and dispatches a vehicle to remove the loaded tray from the line-side position.

The two logistics flows share the same fleet and scheduling system, but their task triggers are not the same.

Why We Treated 'Deliver Empty Tray + Pick Up Full Tray' as One Complete Logistics Cycle

If an AGV performs only one-way tasks, a large amount of empty travel can be created.

For example:

An AGV delivers an empty tray to the production line and then returns empty.

Another AGV later travels to the same area to collect a full tray.

Functionally, this can work.

But the valuable part of vehicle time is:

Carrying Load

not:

Driving Empty

For fleet-capacity calculations, this project therefore treated one AGV cycle as a compound operation:

Deliver one empty tray while bringing back one full tray.

In other words, the route was designed as far as possible around:

Empty Tray Delivery → Full Material Pickup → Return

rather than two fully independent:

Delivery Trip

and

Pickup Trip

This reduces unproductive empty mileage.

AGV efficiency therefore should not be evaluated only by:

Vehicle Speed

A more useful question is:

How much useful material movement is completed during each vehicle cycle?

If one route can complete both delivery and pickup, the same number of vehicles can perform more useful logistics work.

Why the Vehicle Needed Four Onboard Buffer Positions

The roller AGV used in this project was not designed with only one simple load position.

The vehicle incorporated:

4 Buffer Positions

The purpose was not simply:

To carry more trays in one trip.

More importantly, multiple onboard positions reduced the need for the AGV and production equipment to be perfectly synchronized at every handoff.

If the AGV could carry only one tray, every exchange would require the vehicle to arrive, dock, transfer, and leave before the next material movement could happen.

With several onboard buffer positions, one vehicle can manage multiple trays during the same logistics cycle and reserve different positions for empty and full trays.

This effectively turns the AGV from a:

Single-Load Transporter

into a logistics node with some:

Mobile Buffer

capability.

However, additional buffer positions also make the control logic more complex.

The system must know:

• which onboard position is currently empty;
• which position contains an empty tray;
• which position contains a full tray;
• which position should be used for the next handoff;
• which roller section must align with the target equipment;
• whether the remaining positions can continue operating if one position is abnormal.

Adding buffer positions therefore does more than increase carrying capacity.

It changes:

Transport Logic + Docking Logic + Task Scheduling

Why a Route That Works for a Manual Forklift May Not Work for This AGV

One of the most obvious constraints in this project came from the existing aisle space.

The route analysis indicated that straight AGV travel required at least approximately 1,100 mm of aisle width after accounting for safety clearance on both sides of the vehicle.

If the vehicle needed to rotate or turn locally, the space requirement increased to approximately 1,625 mm.

These figures directly influenced route planning.

If the system had been designed only around the shortest possible route, vehicles might have needed to turn, reverse, or pass each other frequently.

The existing injection molding workshop aisles could not necessarily provide enough room for those movements.

For this reason, the project did not simply pursue:

Shortest Route

Instead, the main longitudinal aisles used a:

One-Way Circular Route

Although this can increase travel distance for some tasks, it reduces:

• head-on AGV encounters;
• turnarounds in narrow aisles;
• traffic conflicts;
• intersection waiting;
• multi-vehicle deadlock risk.

This reflects a practical trade-off in AGV route design:

Shortest Distance does not necessarily mean Highest Throughput.

A shorter bidirectional route that frequently creates waiting may have a longer real task cycle than a slightly longer but more stable one-way loop.

Why the Central Area Needed Dual-Lane Pickup and Drop-Off

Material handoff points are often more likely to create congestion than the main AGV travel aisles.

That is because an AGV does not leave immediately after reaching a handoff point.

It still needs to:

• position accurately;
• dock with the roller interface;
• wait for equipment permission;
• start the conveyor transfer;
• confirm tray arrival;
• complete task feedback.

As a result, a vehicle typically occupies a handoff position for much longer than it occupies a normal section of aisle.

Because this project needed to support both empty-tray delivery and full-tray pickup, the central area used a dual-lane pickup/drop-off concept to reduce the probability of vehicles queuing for the same interface.

The real issue here was:

Docking Point Capacity

not only:

Road Capacity

Even if the main AGV route is completely clear, overall logistics throughput will still be limited if every vehicle must queue for one handoff point.

AGV capacity analysis therefore cannot look only at:

How many vehicles are in the fleet.

It must also consider:

How many vehicles can complete pickup or drop-off at the same time.

Why We Selected a Roller AGV Instead of a Basic Transport AGV

The loads in this project needed to transfer automatically between the vehicle and line-side equipment or roller conveyors.

With a basic load-carrying AGV, one question would still remain after the vehicle arrived:

How does the tray move from the AGV into the machine-side equipment?

If this transfer still requires an operator, the system only achieves:

Automated Transport

rather than:

Automated Material Handoff

The project therefore used a roller-type AGV so that the vehicle itself could actively transfer trays and dock automatically with production equipment or roller conveyors.

The logistics sequence could then become:

AGV Arrives → Docking Confirmed → Roller Starts → Tray Transfers → Position Confirmed → AGV Leaves

rather than:

AGV Arrives → Operator Moves Tray → AGV Leaves

This distinction is critical in an unmanned logistics project.

True unmanned material flow requires automation of both:

Travel

and

Handoff

Automating only one of them still leaves a manual transfer point.

Why Reaching the Correct Position Was Not Enough to Complete the Handoff

A mobile robot can navigate to the correct target position and still fail to transfer the load successfully.

A reliable automatic handoff also depends on:

• final AGV stopping position;
• vehicle roller height;
• machine-side roller height;
• conveying direction on both sides;
• tray bottom structure;
• mechanical guides;
• positioning tolerance;
• sensor status;
• PLC signals;
• motor start conditions.

The project therefore included interface modifications for the tray-arranging equipment, roller conveyors, and machine-side docking points rather than deploying vehicles alone.

This addresses a common misconception in unmanned logistics:

If the AGV positioning accuracy is high enough, it can automatically dock with any existing equipment.

In reality, the AGV is only half of the interface.

The other half is the existing equipment.

Only when:

Vehicle Interface

and

Machine Interface

share compatible mechanical, electrical, and control conditions can the system achieve stable automatic handoff.

Why Fleet Size Could Not Be Determined Directly from the Number of Machines

If a workshop contains dozens of injection molding machines, that does not mean every machine requires its own AGV.

At the same time, we also cannot simply assume:

One AGV can serve many machines, so the fleet should be kept as small as possible.

Fleet size should come from the logistics workload.

At minimum, the calculation needs to consider:

• empty-tray demand per hour;
• full-tray pickup demand per hour;
• distance per transport task;
• length of the one-way circular route;
• handoff time;
• vehicle waiting time;
• number of trays carried per trip;
• whether empty delivery and full pickup can be combined in one cycle;
• charging and other non-transport time;
• peak task density.

The project therefore did not configure vehicles directly from the number of injection molding machines. Instead, one complete compound operating cycle was used as the calculation unit, and the required roller AGV fleet was derived from the actual logistics demand.

The logic was:

Material Demand → Task Frequency → Compound Cycle Time → Vehicle Capacity → Fleet Size

rather than:

Number of Machines → Number of AGVs

Why the Scheduling System Did More Than 'Send an Available AGV'

With one AGV and one pickup point, task dispatching is simple.

Once multiple vehicles operate simultaneously and need to support several injection molding machines, empty-tray delivery, and full-tray pickup, the problem becomes much more complex.

The system architecture in this project connected ERP, MES, WMS, AGV Scheduling, RCS, WCS, and field-level equipment execution.

When production equipment requests an empty tray, the system cannot ask only:

Which AGV is currently idle?

It also needs to consider:

• where each vehicle is currently located;
• which onboard buffer positions are still available;
• which route is currently available;
• whether the vehicle can collect a full tray on the same trip;
• whether the target docking point is occupied;
• the priority of other tasks;
• whether the vehicle needs to charge;
• whether there are current traffic conflicts.

The true scheduling object is therefore not just:

Vehicle

but:

Vehicle + Load + Buffer Position + Route + Docking Point + Production Task

This is why individual vehicle navigation alone is not enough to guarantee high system efficiency once the fleet and task complexity increase.

Why the Digital Twin Was More Than a 3D Display

The project also included a browser-based digital twin.

The system could be viewed on large displays, PCs, smartphones, tablets, and televisions, and the scene could be adjusted to a certain extent without programming.

If a digital twin does nothing more than show an AGV moving across a 3D map, its practical value is limited.

The more useful function is making the actual logistics state observable.

For example, the central control platform can help management view:

• current AGV locations;
• equipment operating status;
• storage or position status;
• current logistics tasks;
• call status;
• equipment alarms;
• dynamic task activity.

This means a question that would previously have required someone to walk to the workshop:

Why has this material not arrived yet?

can be broken down into more specific questions:

• Was the task created?
• Which vehicle was assigned?
• Where is the vehicle now?
• Is it waiting for a handoff?
• Which device is abnormal?

The value of digitalization is not simply to make the logistics system look more intelligent.

It is to turn:

an invisible logistics process into data that can be observed, analyzed, and acted on.

Why Exception Recovery Had to Be Designed Before Unmanned Operation

This project also exposed a very practical issue: if the AGV, tray arranger, or roller conveyor encounters an abnormal condition, the current logistics task may no longer be able to continue.

Under the original recovery approach, operators needed to:

• cancel the task;
• reset the AGV;
• reset the tray arranger;
• reset the roller conveyor.

The recovery process was relatively cumbersome.

This highlights an issue that is easy to overlook in automation projects:

Automating the normal process does not automatically mean the system is ready for unmanned operation.

When every device is operating normally, the automated logistics flow may appear very smooth.

The real test is:

What happens to the task when one part of the system fails?

The solution therefore needed not only automatic task assignment, but also a more centralized way to manage abnormal states and recovery operations.

That reduces the need for operators to enter several independent device systems and decide:

Which piece of equipment should be reset first?

For a long-running unmanned logistics system, availability is often influenced less by how fast the equipment runs under perfect conditions and more by what happens after an abnormal event.

The key question becomes:

Can the system quickly identify the problem and restore the logistics task with as little manual intervention as possible?