Keywords

1 Introduction

The manufacturing industries are in need of change in the production from producing high volume and low variety to high volume and large variety of customization. This demand increases to adopt the flexibilities for customizing their products, which leads to flexibility in the manufacturing systems [1]. There are several concepts to achieve flexible manufacturing in production. The manufacturing systems have encountered a variety of evolutions. Dedicated Manufacturing Systems (DMS) are expensive to adopt since it requires a lot of time for any change in the manufacturing product specification. Because they are manufactured to produce only a specific type of product for the whole lifetime. This enables the manufacturer to manufacture a low-cost product with a huge volume of quantity or mass production. These types of solutions are well established in an optimized way to produce high throughput and energy-efficient production rates for their lifetime. If the manufacturer wanted to change the specification of a product during the production, DMS cannot accommodate any change in the production as these systems are static [2].

Flexible Manufacturing Systems (FMS) are built to produce a range of similar products which can be realized through programmable devices, e.g., Programmable Logic Controllers (PLC’s) and industrial robots. PLC’s and the programming flexibilities gives a manufacturer the possibility to manufacture a certain range of similar products [3, 4]. Since these systems are bulky and have low utilization of their functionalities due to certain products, it leads to high initial cost and less production rate compared to DMS. Even though researchers are working with many variants to improve the production rate in FMS it is limited due to its basic design. To overcome these constraints in the manufacturing system, researchers are working towards Reconfigurable Manufacturing Systems (RMS) [5]. RMS can prove to have a combination of a higher production rate closer to DMS but still with the flexibility of FMS. Reconfigurability can be achieved by the application software, design variables and Human-machine interface (HMI) [6]. Reconfigurability of RMS includes its wide range of subsystems to make a complete automation. Here the subsystems are for example machining, machine tools, fixturing, assembling, material handling, and control. To achieve reconfigurable production systems in the industry, often knowledge of external competence is required which most of the manufacturers are lacking.

To overcome these issues, the implementation of the Plug & Produce (P&P) concept using Multi-agent System (MAS) is proposed. In the manufacturing process when mass customization is required, P&P concept is adopted to add or remove a module in a quick and easy manner. P&P concept means it addresses the physical aspect of flexibility and allows a quick reconfiguration of the process modules. Hence, the system can easily adapt to the new production situation based on the new product variants and new customization. To enable this P&P concept, a multi-agent system concept is proposed [7]. The use of MAS technology addresses the flexibility in terms of software that can be logically controlled [8]. It contains distributed individual intelligent agents throughout the manufacturing process which can negotiate (interact) with each other to make decisions [9, 10]. Thereby these agents can solve more complex tasks by negotiating new solutions, which a single agent cannot solve.

Fig. 1.
figure 1

Example of a Plug & Produce system using agents to perform an operation.

Full size image

The agents can be represented as parts to be processed in some manufacturing process and resources, such as a robot or a gripper. A simplified example of the Plug & Produce concept using MAS is shown in Fig. 1, here the agents can communicate to other agents to perform the transporting task. For example, the robot would first attach the gripper tool that in turn grips the part at station 1, then move the part to station 2. Within this type of solution, the agents representing robots can request a robot path in order to fulfil a goal of transportation [11]. These paths must be automatically generated and deployed online to facilitate a fully autonomous system, otherwise, all paths must be manually created and stored in advance. Online meaning is that it can generate a path instantly or during the production when the agent requests it. In this article, a path planner agent is described that automatically deploys a path when a start and goal point is given. For path planning, it uses the sampling-based algorithm Rapidly exploring Random Tree (RRT) [12]. The RRT algorithm is validated by Ramasamy et al. previously to be used as a path planning algorithm in Robotstudio simulation environment [13, 14] and tested with P&P environment [15] and a sample of generated path is shown in Fig. 2.

Fig. 2.
figure 2

A sample of a generated path from the path planner [11].

Full size image

In this paper, a configurable multi-agent system is used (C-MAS). This means that agents are configured rather than programmed. The configurations contain the configuration classes and configuration entities defined in a configuration tool. Figure 3 shows a simplified example of how an agent configuration can be described in a configuration tool.

Parts and resources can have variables; in this Fig. 3 one variable is defined that identify the position of the parts and resources. Also, more complex variables such as CAD geometries could be also included. Interfaces are defined to identify the compatibility for connecting agents together, in this case: the part, gripper and robot. The part has a goal i.e., part has to be moved from station 1 to station 2. The goal needs a process plan to be reached. Process plan means the list of skills to be executed to achieve the goal. The process plan contains demands for interfaces, for example to grip a part, it needs a gripper interface. The interface has an instruction to run a skill that must be executed to perform that gripping operation. Again, the skill has a process plan to complete the gripping action. The motivation towards this project is achieving an agent-based path planner in the P&P environment. The reason for the path planner in the P&P environment is, we move the process modules around the cell depends on the needs and applications. For that purpose, we need an automatic path generator to generate the path instantly based on the agent requirements. This requires updated model of the P&P environment. In a future approach the simulation could be updated online based on incremental changes in the layout of the cell. In this article, an agent-based path planner is implemented as one of the agents in a multiagent system. For generating the path RRT path planning algorithm is employed. When a robot agent requests for a path, the path planner agent will fetch a path from the database if it is already generated for the same location with same environment, otherwise the path planner will generate a collision free path from the implemented RRT algorithm.

Fig. 3.
figure 3

Agent configuration classes

Full size image

2 Manufacturing Scenario

A manufacturing scenario is created for a simple task of transportation with four agents. One agent represents the robot (it is a robot), the second one is a part agent (the part to be transported), the third one is a path planner agent (the path to be generated based on the start and goals points), and the fourth one is the gripper agent to grip the part. There are two stations, and it is stationary where the part can be moved from one station to the other station. If it is not a stationary station, these two stations may also be represented as an agent in MAS. But here it is assumed as a stationary object, so it has the same coordinate system as the robot. All the four mentioned agents can be configured to have their own goals for parts, skills for resources and all the agents have variables and interfaces. For example, when configuring the gripper agent, it is initialized with variables that define the coordinates for pick and place positions for the gripper to perform any transporting operation. Interfaces are where the agents connect and interact with each other. Skills for resources and their variables for interacting with other agents are also located on the interface. When we use a part with a resource, then the part agent and resource agent should have a matching interface, so that these two agents can interact with each other. Here the part is having a goal for transporting operation. To achieve this transporting operation, part search for a process plan. The process plan contains the set of instructions to perform the goal. The first instruction must call a robot gripper to perform the movement skill. From the move skill the gripper needs a robot to move the gripper. It finds the robot and lets it move the gripper. The robot realizes that it needs a path to move from station1 to station 2. Now the robot calls the path planner that has a skill of path generation, when the path generation skill is performed, a path is generated in the path planner agent, and it is sent to the robot agent where the robot performs the skill of transportation. When the robot agent calls the skills, it sends with a variable called PathID.

Table 1. A simplified example of agent configuration to implement the manufacturing scenario with skills for resources and goals for parts.
Full size table

The path planner saves all the generated paths with the corresponding PathID. Each time a new path is requested the path generator checks with the PathID information along with its environment in the database. If already a path is generated for this environment, it will retrieve the same path from the database otherwise path planner generates a new path. The process plan for transportation must find the position to grip the object. Table 1 shows a simplified example of how the configuration of each agent could be configured for this scenario. Here the coordinates of two stationary stations are given as variables in the robot agent.

The Part agent will communicate to the GripInterface on the gripper agent so that it can grip the part. This is done by setting the inputs GripPartPosition and UnGripPartPosition on the gripper based on the Station1Position and Station2Position. Any needed translation of coordinates can be defined on the process plans for goals and skills in each agent. The gripper finds the robot on the interface TransportInterface and forwards the positions to the GripToolPosition and UnGripToolPosition. The robot needs a path and connects to the path planner on interface PlannerInterface and calls the skill GeneratePath with PathID, StartPoint and GoalPoint. If needed, the gripper could also hold its tool data and each agent could have attached CAD geometry data to be used in the path planner. When a path is generated, the robot can access the GeneratedPath on the path planner through the connected PlannerInterface.

3 Design and Implementation

The path planner is implemented as an add-in software for ABB RobotStudio, implemented in C# using Microsoft Visual Studio. Figure 4 shows the overview of path planner code structure. The path planner was divided into three parts: “Extensible Markup Language (XML) files”, “Main functions”, and “Supporting functions and classes”. The XML files are used to create add-in control buttons in RobotStudio, where these buttons can easily be used by humans. The main functions contain “PathGeneratorAddIn” and “PathPlanner”. The PathGeneratorAddIn executes commands triggered by the controls defined in XML files and the PathPlanner contain the path planning algorithm for transportation as the main function. The supporting functions and classes contain a function for creating a range of workspace, a collision detection module, a path smoother and a function to save the program. The collision detection function was enabled by simulating the robot’s movement in its configuration space which is created in the RobotStudio simulation environment.

Fig. 4.
figure 4

Overview of the path planner code structure.

Full size image

A sampling-based RRT algorithm is used to generate a collision-free path for transportation. The path planner is implemented as an agent. The path planner is in this paper connected to a multi-agent system and the requirements for this path planner agent are:

  • Start and goal points should be fetched automatically from other agents.

  • Each path generated should be saved automatically.

  • Expecting a feasible path solution always if the one exists.

  • Path planners can have any path planning algorithm such as RRT, since we use path planners as an agent.

Based on these requirements the proposed system is shown in Fig. 5. In the agent system, the path planner agent has a skill which is called as GeneratePath and robot agent has a skill which is called as MoveTool. The path planner service input and output are written in JavaScript Object Notation (JSON) [16] format. An agent can request a path by sending start and goal points to the path generator. The path generator generates a path, forwards the path to a requesting agent and saves the generated path in the path database along with start and goal points and information about the environment. The information about the environment means it contains robot position, tools, modules, and fences. When a new path is requested always the path generator compares checks a path that is saved already in the database in comparing with start and goals points and information about the environment. If everything matches it will retrieve the stored path and send it to the agent. If any one of the parameters is not matching, the path generator will generate a new path based on the data provided and send it. Thereby if it needs to generate the same path again it saves the computational time of the path planning algorithm. Any type of path planning algorithm can be easily exchanged or modified in the path generator, it doesn’t require to change any communication between the agents and path planner or between the agents. Here the limitation is the path generator is implemented in RobotStudio, so it can accommodate only ABB robots. Agent based Path planner service contains a path generator (the main program), inputs in JSON format and output (generated path) in text format which is shown in Fig. 6. Path database contains the path folder and path input storage. The path folder contains the module file and program (PRG) file. Module file contains tool data, robot targets and move instructions.

Fig. 5.
figure 5

Proposed system design where the agent system is used to communicate between a robot (on the left) and a path planner service (on the right).

Full size image
Fig. 6.
figure 6

Agent-based path planner service

Full size image

As long as we have a module file in the path folder the content of PRG file will not change. It means that the module file only needs to be sent as output to the agent (path in the text format). Input consists of start point, goal point, path identifier (Path ID) and it is sent to the agent system in the format of JSON data strings. The start and goal points are represented as position \((x,y,z)\) and orientation \(({r}_{x},{r}_{y},{r}_{z})\) of the points. The path ID is a string value and output is in the form of RAPID (ABB robot’s programming language) program which can be sent as a text file to the agent system. When a path is generated, it will be saved in the path database with the following structure shown in Table 2. Each path input corresponds to 13 lines of text. Those are the start point comprises of 6 lines i.e., 3 for position and 3 for orientation, similarly goal point comprises of 6 lines and the last line carries the path ID. Then the new path information will be appended and so on. Use of visual studio project properties “Post build event command line” enables the path generator code will be automatically saved in to RobotStudio API reference. This procedure copies the path generator add-in’s DLL file to RobotStudio’s add-in directory whenever the solution is rebuilt in Visual Studio. After configuring the agents, the communication between the path planner and the agent system is tested with a simplified scenario. The scenario is created in RobotStudio with robot installed in it, not with the actual robot connected to it. So, the part variables and robot variables are not needed for this simplified test. The goal is, path planner must generate a path upon the request from the part agent. For testing, part agent, path panner agent and the robot agent must be online in the agent platform server. Steps to perform the test is given below.

  • Part agent finds its goal and search for process plan (goal is transportation).

  • Process plan demands an interface with a skill (skill is to move part from station 1 to station 2).

  • Gripper requests assistance from the robot.

  • Robot agent requests for a path from path planner.

  • Path planner needs data (start and goal points with path ID) to generate a path.

  • Robot agent retrieves data from part agent and sends to path planner.

  • Path planner checks for a path from database, if exists sends it otherwise generate and sends to robot agent.

  • The robot agent confirms that it received a path by printing a short message.

Table 2. Generated path storage structure in path database
Full size table

When the agents can communicate, the part agent can request the gripper agent for transportation, the gripper can get assistance from the robot to move the gripper, the robot agent can request the path planner for a path to perform transportation, the path planner can generate a path based on the algorithm implemented in it and sends to the robot agent. The above steps i.e., the communication and path generation between the agents was established and is validated by looking at the output from the path planner to see if it was corresponding to the data that was expected by the agent system. Thus, this paper has designed and implemented a functioning path planner agent.

4 Conclusion

This paper presents a path planner agent that can act as a service in a manufacturing cell. The path planner agent is developed and implemented successfully with an agent system for the simple manufacturing scenario presented. The agent system presented in this paper was used for communication and to store configured data such as the positions for stations 1 and 2. A robot agent was designed that can communicate with the path planner through the agent network and request a path to be created. The path planner is reusing paths by saving any previously generated path along with its environmental data and path id. This reduces the computational time of path generation and in some cases eliminated, since the path planner agent is fetching a path for the environment if the path exists. We found that the implemented path planner agent can negotiate, interact and communicate with other agents to generate a path, thereby it completes the goal of transportation.

As of now, we have modelled a robot in robot studio to test this agent concept and implemented a sampling based RRT algorithm as a path planning algorithm in the path generator. Currently, working on establishing online communication between the robot agent and a physical robot. For future work, we will investigate adding other sampling-based optimized path planning algorithms in the path planner agent. When a robot agent requests to generate a path, the path planner agent will be able to choose the algorithm based on the needs for example less computational time or a less energy-consuming path.