Voice warehouse automation

  In this article, I am going to talk about a project in which I was involved and had the position of the main developer. I’ve gathered a lot of experience by passing through all the project phases:

  • Approving the specifications;
  • Development;
  • Inhouse testing;
  • Onsite testing;
  • Go live.

  I am going to describe a few of the main aspects of the company which requested our services and how our product helped them.

Bavaria – The Client

  Bavaria is the second largest beer companies in Netherlands. It was founded in 1680 and it produces over 500 million bottles of beer per year. It has two warehouses in Lieshout and De Meern. In addition of producing beer, they also activate in food industry, by serving food and beverages under the name HORECA.

  In their warehouses, the operators pick up the orders from different customers. For example, a customer wants 5 boxes of beer and 10 bottles of water. The operator has to walk through the warehouse and find these articles. He has to get the necessary amount of articles and bring them to a dispatch zone.

The Problem

  Of course, all this was done on paper. The operator did not have a safe way of picking these articles without making some mistakes. He used to walk randomly through the warehouse searching for the specific articles. The orders were not prioritized and they did not know the exact location of the articles. Basically we can easily define some organizational problems:

  • Complex interaction between the operator and customer order;
  • Messy or disordered work flow inside the company’s warehouse;
  • Unequal distribution of orders per operator;
  • Enormous amount of time spent to complete an order for a consumer
  • Chaotic way of walking through the warehouse to pick the necessary items for an order.

The Data flow and resources

  The customer Orders are printed from SAP and given to the operators. After the orders have been picked, they were reported back to SAP. Therefore, the flow is simple:

  • Print from SAP;
  • Pick;
  • Report back to SAP.
untitled-1
Fig. 1 Manual picking flow

  However, if we have a closer look into this, it involves many resources like:

  • A big number of operators;
  • A big amount of paper for printing the commands;
  • SAP specialists for printing needed orders;
  • Of course, you need a high salary budget to cover all the operators.

Justification of our product

  After a brief analysis of the resources and technologies they were using, we saw a need to change the way the company worked. We had to automate as much as possible, so we did. Our system maximized the workforce efficiency and the warehouse has employed fewer workers. As a result, we have decreased the possibility of injuries to operators in the warehouse, reduced the margin of error produced during gathering of items and definitely it had a financial advantage for the company. It was offering fewer taxes, salaries and compensations for each wrong picked order. Here is what we improved:

  • We know the exact location of articles;
  • We compute the exact route per operator;
  • We prioritize the Orders per day, week etc;
  • We introduced a simpler way of picking the order via voice terminals;
  • We reduced the time spent on orders.
chart
Fig. 2 Manual vs Automated solution

  Yes, voice, you read it right. The operator does not need a pencil and paper anymore. He has a voice terminal in his pocket and he receives all the instructions on his headset, like where to go and how many items to pick. We also offered a web interface where the supervisors could have a look at the orders and their status.

Inther LC – The Product

  The software we develop is called IntherLC. We’ve installed it on the Bavaria’s server and we’ve made some changes to the flow in the warehouse.

untitled-2
Fig. 3 Automated picking flow

  Now IntherLC gets orders from SAP, we call this the interfacing process. Then in our system we release them and create batches of instruction per order. After that, we manage the operators and their actions over the orders. When an order is completely picked, we send back a report about that specific order. Easy, isn’t it?

  As input, we have only the orders, but as output, we have different kind of reports like:

  • Outbound report that is sent back when the order is finished;
  • Web reports related to the orders and operators;
  • Dashboards.
menu
Fig. 4 Dashboard menu

overview
Fig. 5 Picking overview

chart2
Fig. 6 Order report

Technology stack

  A big part of our system is written in Java, but we still use other languages like:

  • Python;
  • C#;
  • JS and all kind of web frameworks like JSF and Angular.

  We use frameworks and libraries like:

  • Hibernate;
  • Spring;
  • Camel;
  • ActiveMQ
  • Jetty

Voice, TTS and vice versa

  At Bavaria, we have 14 voice terminals that run on Windows CE OS. On them we run our C# application called Audora that plays text and can recognize the voice. The idea of Audora Application is to play IntherLC tasks received via TCP and convert user voice responses into text and send them back to IntherLC.

  Our system handles all the operators in separate threads. Each operator has his own session and a batch of instructions. When the server sends a task like going to a location, then Audora simply plays an audio in the operator’s’ headset.

  As I mentioned before, each task has to have a reply. The reply is recognized via a library called Nuance. This is a very powerful offline voice recognizing library, written in C, although they offer a Java JNI wrapper as well. It has a bunch of properties to adjust for the voice recognition.

audora
Fig. 7 Communication between the Host and Audora

Conclusion

  I really enjoyed working on this project and I’m glad to see it live. It really makes me happy and I kind of forgot all the days and nights I’ve been hitting the wall trying to solve an issue.

Share this article:

Dan Cebotarenco
Java Developer