Use Case
Delivery on Demand in a production line by using a Makeblock Rover and a DOBOT RobotArm managed by a central controlling server system used with an ADOxx user interface
Use Case Description (Making a pizza): Following a line, avoiding obstacles and placing products on the right place
The DOBOT RobotArm is placing products that are needed for production on the right place of the production line (will be read from the ontology). As soon as a product is needed, that is not available in the storage, the Makeblock Rover is following a black line that stops right in front of the Arm and brings the missing product. When the Rover sees an obstacle it stops, makes a turn, hopefully stops at the black line again and follows it to the end. As the rover stops at the end of the line it makes a 180 degrees turn and lets the arm pick up the product and place it on the right place on the production line. The function of these two cyber physical systems are saved in the server and can be defined with a conceptual modeling method, implemented with the ADOxx platform.
Use Case 1: Initial state of the server, moving the DOBOT RobotArm and initial state of the modeling method
Use Case 2: Adaption of the server and the modeling method, implementing the car functionalities
Use Case 3: Saving the product and the places in a new created ontology, final state of the server and the modeling method
In the picture the use cases can be seen graphically. There is the Rover with the missing product that is driving along the black line, detecting and stopping in front of an obstacle, avoiding it and turning around at the end of the black line. We can see the that is placing the products from the storage on the production line and picking up the missing product from the car and placing it also on the production line. The positioning of the products and places are saved in an ontology. And we have our central controlling server system, where the cyber physical systems are registered and their availability is controlled regularly. Also, their functions are saved in queue and can be executed.
Problem Statement:
- Coordination between cyber physical systems
- Managing the production in a centralized server system
- Intuitive user interface for configuration of the processes and the cyber physical systems
- Semantic enriched saving of products and places
- Communication between cyber physical systems and the centralized server system
- Making good pizza
Overview:
The most challenging aspect of this project is the central controlling server system and its communication with the cyberphysical systems and the ADOxx modelling toolkit.
Experiment
Our experiment was to simulate the production of a pizza by creating cards that illustrate components of a pizza and ordering them based on the wanted pizza. The configuration of the different steps needed to create the pizza was defined in models and sent to controlling system. The controlling system saves the functions of the cyber physical systems, the pizza creation process, and finally triggers the execution. One component is missing at the production line and must be delivered from a car.
Experiment Execution:
First the controlling system, which can be found with the following GitLab link, must be started:
There it must be downloaded/cloned and the maven install command must be executed. Afterwards the “DeliveryOnDemandServer.jar” can be executed.
For using the arm, the token (which can be gathered from the OMiLAB homage) must be added to the “config.properties” file. In this file, also the values for using the test implementations can be set. If “cpsTest” is true, then there will be only printed messages to the command line and no CPS interface is called. The property “adoTest” can be used to toggle if messages should be send to an ADOxx instance or not and “daoTest” specifies if the test data or the ontology is used to get the coordinates of the places and products. The URL, under which the ADOxx instance can be reached, can be configured with “adoEndpoint” and “serverport” specifies, under which port, the Jetty server is started.
For using the rover, the webserver on the raspberry pi must be started manually. Therefore, a connection over a ssh must be established and in the “RoverServer” folder, the jar file (in the target folder) can be found. The project can be updated with “git pull” and the jar recreated with the “mvn package” command. The source code for the “RoverServer” can be found under:
To use the modelling method, the ADOxx library, which also can be found in the GitLab project semtech_group4 must be imported in the ADOxx platform and started. After models are created or the one from the GitLab project are imported, the CPSs and the process can be registered. Therefore, the “P&D” menu and its entries can be used. As a last step, the “Execute process” command can be used, to trigger the execution of the process. In the controlling system project, also the used AdoScripts can be found.
A test case, which uses ADOxx to register CPS and processes and executes one process, can be seen in the video in the result section.
Structure of the controlling system
If one wants to adapt the controlling system: in the “forTesting” package are classes, which were used to test the different parts of the system. In the “resource” folder under json, examples for the JSON files, which are sent towards the controlling system, can be found. Also, the ontology (in turtle format) and the sparql queries can be found in the “resource” folder.
The packages “com.boc_eu.adoweb.adows” and “org.adoxx.adows.client”, were taken from the BOC (Link) and are used to communicate with an ADOxx instance. The communication is handled from the classes in the package “adoxx.adoscript.myWSclient”, which contain a test class, an interface and the real implementation, which inherent the needed functionality from classes, which are taken from the BOC.
The “callCPS” packages, contains the classes with the REST calls of the CPSs and the “dao” package offers the functionality, which is used to get the coordinates from the ontology. The “model” package contains the different classes, which holds needed information or functionalities. Last but not least, the “process.management” package takes care of the management of the processes and the CPSs.
Results
In the following video, you can see how the server saves and executes the functions and processes of the CPSs, using the ADOxx modelling tool. Afterwards a process is started, the execution is shown in the modelling tool and the CPSs are executing their tasks.
To improve the project in the future, the following points should be addressed:
- Add decisions to the process model and the process execution in the controlling system
- Add parallelism to the process model and the process execution in the controlling system
- Implement an algorithm, for what a CPS should do, if it should execute action for different processes
- Improve the movement of the rover, by consider more sensor input (maybe add sensors) to the drive functions
- Improve coordination between the robot arm and the rover, by using the OMiTAG coordination system
- Implement the automatic registering of the CPS, during their start-up
- Improve the visualisation of the modelling method
- Also of the visualisation of the process execution
- Improve the stability of the SOAP interface of the ADOxx platform
- Maybe implement an algorithm, which saves the actions, which should be done for a process, directly by the CPSs and they only give feedback to the controlling system
- Here also a new algorithm for changing the representation in the ADOxx platform is needed (now the object and the model id is saved by the registration)
- Implement a logging, for the controlling system