Key takeaways
- Your WMS or MES decides what moves; the dispatch system decides which robot, which route and when to charge.
- Send transport tasks to the dispatch system, never commands to individual robots.
- Agree task fields and status events first, and book stock only when a load is delivered.
- Keep one shared location table for system locations and robot map points.
- Plan exceptions and test against a simulator before robots arrive on site.
Who does what
An AMR integration has three layers. Your WMS or MES decides what needs to move and when. The robot dispatch system decides which robot does it, which route it takes, how traffic is managed and when robots charge. The robots carry out the moves and report what happened.
Your business system should not talk to individual robots. It sends transport tasks to the dispatch system and receives confirmations back. That keeps the interface small, lets you add robots or robot types without changing your WMS or MES, and keeps traffic and charging logic in one place.
Ways to trigger a robot task
Not every task has to come from the WMS or MES. Most sites combine several sources:
- System tasks: the WMS creates put-away, replenishment or outbound moves, and the MES calls material to a line or removes finished work.
- PLC signals: a machine, conveyor or line end signals that a load is ready or that a station needs material.
- Call buttons or tablets: an operator requests a pickup or delivery at a station.
- Scheduled tasks: fixed rounds, such as moving empty carts or pallets every hour.
What a transport task contains
Agree the content of the messages before anyone writes code. A transport task usually carries:
- A unique task ID from your system, so every message can be matched.
- Pick-up and drop locations, using names that exist in both systems.
- The load: pallet, cart or tote ID, and the load type if it changes how the robot handles it.
- Priority and, where it matters, a deadline.
What the dispatch system reports back
Status messages close the loop. Typical events are task accepted, robot assigned, load picked up, load delivered and task failed or cancelled, each with the task ID and a time stamp.
Book stock movements only on the delivered event, not when the task is created. This keeps WMS stock locations accurate even when a task is delayed, cancelled or finished by hand.
Locations: the step most projects underestimate
Every pick-up and drop point exists twice: as a location in your WMS or MES, and as a point on the robot map. Keep one shared table that links them, with an owner who updates both sides when a line, rack or station moves.
Decide early how precise each location must be. A floor position in a staging lane is simple. A rack level, a conveyor transfer or a machine port needs exact positions, and sometimes a signal exchange with the equipment before the robot loads or unloads.
Common interfaces
Most robot dispatch systems offer a documented API, often HTTP with JSON messages, for creating tasks and receiving status updates. Some projects put a small middleware layer between the business system and the dispatch system to translate formats or combine several systems.
Machines and conveyors are usually connected through PLC signals, either digital I/O or an industrial protocol such as Modbus TCP or OPC UA. Automatic doors and lifts are connected the same way, so robots can open doors and call lifts on their own.
VDA 5050 is an open standard for communication between a master control system and mobile robots from different brands. It can help in mixed fleets, but most projects integrate at task level with the dispatch system. Ask your supplier which interfaces they support and request the interface documentation before you sign.
Plan for exceptions
Most integration effort goes into what happens when a move does not go to plan. Agree in advance:
- Drop point occupied: wait, choose another location or ask an operator.
- Load missing or wrong at pick-up: fail the task and alert someone, never guess.
- Robot fault or low battery mid-task: reassign the task or hand it to an operator.
- Task cancelled or changed by the WMS or MES after a robot has started.
- Network or system outage: how robots behave, and how tasks are resynchronized afterwards.
- Manual moves: how stock is corrected when people move a load the robots were meant to move.
A practical project plan
Start with the flows, not the interface. List each flow with its pick-up and drop points, moves per hour at peak, task source and the confirmation your system needs. Then write a short interface specification covering the messages, fields, status events and error codes.
Test the interface against a simulator or test endpoint before robots arrive, so software issues are solved off the shop floor. On site, test each flow end to end, including the exception cases above, then run it in production for one flow before adding the next. In a typical pilot, integration runs alongside mapping and training, and the pilot goes live in 6 to 10 weeks from the site survey.
How to start
If your IT team is busy, start with call buttons or PLC signals for the first flow, and connect the WMS or MES once the robots are proven. The same dispatch system handles both, so nothing is thrown away.
To get a proposal, send your layout as a CAD file, PDF or phone video, the flows you want to automate and the systems you run. Within 48 hours you receive suggested routes, a robot count and a payback estimate. There is no obligation to buy.
Frequently asked questions
Do we have to change our WMS or MES?
Usually only a little. The system needs to create transport tasks and accept confirmations. If that is hard to add, a small middleware layer or call buttons can bridge the gap at the start.
Can we start without any system integration?
Yes. Many sites start with call buttons, tablets or PLC signals, and connect the WMS or MES later on the same dispatch system.
How long does integration take?
It depends on how many flows and systems are involved. In a typical pilot, integration runs alongside mapping and training, and the pilot goes live in 6 to 10 weeks from the site survey.
Can robots from different brands share one system?
Sometimes. Open standards such as VDA 5050 make mixed fleets easier, but support varies by brand and model. Running one robot family on one dispatch system is simpler to operate and maintain.
Who handles stock accuracy when something goes wrong?
Your WMS stays the source of truth. Book stock movements only on delivered events, and agree how operators correct stock when a load is moved by hand.