Developing a minimum viable product for manufacturing, via third-party robots’ REST API

We know digitalization can be hard. Especially when your core expertise is anything else but software, things can get scary. However, with the right partners and an agile approach, you can easily develop a minimum viable product (MVP), learn quickly, and build the confidence to scale.

So, let’s deconstruct a recent project we did for a manufacturing client.

Status quo

For any manufacturing company, investing in technology (whether machinery or software) is a must. In order to make the most out of the (usually expensive) acquisition, one needs to use machinery at full capacity.

Our client is no different: the plant manager’s explicit goal is to keep the machines productive at all times. For this reason, he invests significant time and effort to optimally plan and monitor all manufacturing operations.

The optimization needs to address several layers:

1. The planners are in charge of establishing the production quota for each machine during each shift, day, or week. They also make sure that all equipment works at the maximum possible capacity.

2. The machine operators do the actual work. For each batch they cover during a shift, the operators must refill their stock of raw materials or pre-processed items. The regular way to do it is to pick a pallet in person, from the warehouse, or from another machine and transport it to the workstation using a mechanical pallet transporter. Once they have the input materials, the operators use the application to record the number of processed items within performance targets (speed, failures, etc.).

Needless to say, the stocking part of an operator’s job was uselessly slow, with a negative impact on overall efficiency.

3. The technology: we had already equipped each workstation with PCs in a minimal configuration to assist the operators during manufacturing activities. During each shift, the operator can see the planned quantity and can record the actual progress. Due to the intuitive interface and pleasant user experience, the system is easy to learn and operate.

In order for us to bring the machines to maximum capacity, we would need to eliminate all useless downtimes. Within this system, the obvious bottleneck was the time spent restocking; therefore, we started looking into automating specifically this phase.

The MIR robots

We were partially lucky. Pretty much at the same time, the Danish robot manufacturer MiR A/S had a demo presentation of their autonomous robots for industrial transportation. Since we’re Kaizen-heads, we loved the idea of integrating them within the existing system.

The robots themselves had everything that our partner needed:

• enough load capacity (several options between 100-1000 kg) on standardized EU pallets;
• working on Li batteries with 12-15 h / 20 km range, the highest speed of 1.5 m/s;
• no structural changes for the existing space (i.e. underground cables, ceiling-mounted sensors);
• operated by PC or smartphone, via WiFi;
• navigation guided by a network of 2D-3D scanners and cameras.

On top of these, the robot was capable of performing a lot of operations, but they were above machine-operator expertise level (and definitely not possible during actual manufacturing):

• map the facility to build an internal plan necessary for autonomous navigation;
• define no-go zones for safe travel;
• define various points of interest on the shop floor;
• define missions, like moving to one point, loading cargo, moving to another point, unloading cargo, etc.;
• schedule missions, one after another;
• define self-care behavior like going to a charging station when the battery is low or going to a designated point when idle;
• connect the robot to the customer’s wi-fi network.

Solution & prototype development

Now “all” we needed was a piece of software to guide the robots from the same PC interface that the plant operators were using for regular manufacturing operations. Ideally, we would make the robot part of the manufacturing cycle and use one single interface for everything related to a manufacturing machine.

Here’s how we did it:

1. The MVP / minimum viable product
First, we’ve put together a two-man team in charge of developing a minimal prototype within two weeks: a piece of software to embed within the operator’s screen (i.e. the one used to record manufacturing activities).

2. Information gathering
The robot offers a REST API that should make it possible to interact with our own software. Well – in theory, at least. Because in practice, API’s extensive manual, covering 330 methods, was neither minimal nor quick to grasp, possibly pushing our minimum viable product’s deadline for several more weeks.

We were lucky once more when MIR A/S’s support team offered an online workshop and access to a virtual machine simulator that acts like a real robot. Suddenly, we could gather information at a much higher speed by testing and training the API’s commands and methods on it. Tracking virtual robots’ movements on the screen provided the instant visual feedback we needed to advance quickly.

3. Prototype delivery/testing
Precisely on deadline, three workstations had the prototype implemented: one single extra button on the operator’s interface to contact the robot and schedule basic missions:

• go to a designated loading point;
• load the cargo;
• transport the cargo to the workstation;
• warn the user if the mission cannot be accomplished (e.g. reason the robot is busy or needs recharging).

Unsurprisingly, all went as planned. The robot + manufacturing interface was functional, and we had the proof of concept that bottlenecks can be eliminated by automating parts of the manufacturing process.

4. Outlook
Before expanding from three workstations to company-wide, the prototype needs testing and observing for several weeks. Further questions need to be answered:

• Will the robot keep finding its way safely around the usually crowded shop floor on a regular and predictable basis?
• Is the robot’s REST API reliable and error-free?
• What are the efficiency gains of using a robot (instead of a human operator) for transporting the cargo pallets?
• How do they perceive and think of robots helping them with their physical actions?

Achievements

Developing the solution was fun and challenging, but it also provided some strong learning points, too:

• Pretty much everything within a company’s scope can be digitalized.
• Digitalizing the core expertise (or activities in its close proximity) delivers the highest value.
• Deeper integration with the client company increases the project’s speed and overall efficiency.
• New projects with big investments are scary. Start with a small team to deliver a minimum viable product, then scale it up gradually.
• Third parties are happy to participate in experiments involving their products, as long as the experiments can be a source of further development ideas.

Next steps

As I write this article, the trial phase is in progress, but we are convinced that the outcome will be positive. Meanwhile, the customer’s operational engineers and the development team are working together to build up the complete feature matrix of this robot integration and to create a release plan spread over the next 6 months.

It’s hard work ahead but the breakthrough was done, and the stage was set for a refreshing and exciting new direction of what would otherwise be a conventional software product.