Use Case
Problem Statement
The main goal of our project is the simulation of a delivery process in warehouses. For this purpose, we have decided to use a robot car (mBot), that represents a delivery part, and a robot arm, which simulates a process of picking a right ingredient from a warehouse. The delivery process consists of choosing the right ingredients from the warehouse and bringing them to the next step for manufacturing, where the final product can be made from them. We suppose that car can carry and transfer only one ingredient at once.
Use Case
The whole process starts with arm initialization, after that the car starts following a line, by using some of its sensors. The car will move and follow the line until it reaches its end, then it stops and waits for a load. After it stops, the arm receives an input for loading of desired ingredient. First, the arm will move to the coordinates of the component, after that it picks it and places it into the basket which is allocated at the top of the car. The car will then turn around and follow the same line back. At its end it stops again and waits for offloading. After that it turns back again. The process of on-loading the ingredient will be repeat three times (for the base, the milk and the sugar).
Experiment
Process Model
Warehouse representation
Abstract model
Our abstract model represents two parts, the production and the warehouse part. In the warehouse part we can see the various ingredients and their total amount available in the stock. The production part represents the final products that can be made from the ingredients. The number of ingredients as well as the amount of each ingredient in a product is different for each product type.
Implementation of abstract model
The picture below represents our implementation of the warehouse. The final product will be an Espresso, which consists of one espresso pad, one milk pack and one white sugar pack.
Knowledge Engineering Concept
We used the ontology from Logical Foundations of Knowledge Engineering for the ingredients in front of the robot arm as part of our knowledge engineering concept. To get the coordinates of a certain product, we used SPARQL queries and Apache Jena.
The pictures below represent an ontology description for ingredient, which is used as a semantic annotation for a business process “Onload ingredient” that can be seen in our business process model. The ontology was created by SeMFIS modelling toolkit. The class is represented by ingredient, its coordinates - x,y,z are object properties that represent a position of an ingredient. The final instances of the class are represented by the bottom part of the picture. Each instance can be open and seen from more detailed perspective; the object type and its corresponding data type properties.
Validation / Technical Experiment
To realize our use case, we used a robot arm and a robot car (mBot). We’ve built a basket using a lego plate and some lego bricks to make sure, that the products won’t fall off the car. The basket was fixed on the top of the car.
The whole project is based on the MBotJava project (https://gitlab.dke.univie.ac.at/OMiROB/MBotJava). We used different functions of the MBotClient class to control the car and some REST calls to trigger the arm movement.
Robot arm
We used the predefined rest interface (http://austria.omilab.org/omirob/dobot1/rest) of the arm for controlling its movements.
For all kind of REST calls, it is necessary to include an authorization token in the header. Otherwise, the arm can’t be controlled. Some of the REST calls also need to contain a JSON formatted payload.
REST resources we used in our project:
/reset
by sending a POST, the robot arm will be resetted and returned back to the initial position
/positionXYZ
by sending a PUT with JSON formatted coordinates, the arm moves to the defined position
/grabOn
by sending a POST, the pump and valve will be triggered
Robot car
To connect to the car, a bluetooth connection between the car and the laptop is necessary.
We used some of the sensors of the car to realize our use case. The most important sensor for our project is the LineFollower sensor, which is used to let the car follow the line. First, we also used the UltraSonic sensor to let the car stop a certain distance away from a “wall”, but we decided to remove the “wall” and just use the end of the line as a stopping point.
Functions we used from the MBotClient class:
readLineFollower - returns:
0.0 if all line follow sensors are on the black line
1.0 if the right sensor is outside of the black line (i.e. car is moving too much to the right)
2.0 if the left sensor is outside of the black line (i.e. car is moving too much to the left)
3.0 if all sensors are outside the black line
motorLeft
needs a speed as an input; used to trigger the left motor of the car
motorRight
needs a speed as an input; used to trigger the right motor of the car
(readUltraSonic)
returns the distance to the next thing in front of the sensor
reset
addListener
First, we treated both parts of our experiment as individual - we validated their functionality and merged them together later. In case of the robot arm we tested whether the coordinates of the ingredients are correct and whether the “pump” function works correctly. After that we focused on the car. As the first step, we connected to the car and tried some functions of the MBotClient class to figure out, what kind of data we get and what needs to be delivered to the functions. We focused on the functions readLineFollower and readUltraSonic. After we figured that out, we created a paper “rug”, where we’ve put a black tape on. The tape represents the route for our car.
To make the car follow the line worked quite fine, however sometimes it happened that the car got out of the black line. This was mostly caused by uneven surface and the speed of both motors. The turning around function was also quite tricky, because it happened quite often that it also got out of the line, this was mostly caused by low batteries, high speed or uneven surface.
Results
