qiuhualiu / scott-eu

SCOTT – Secure Connected Trustable Things

SCOTT sandbox

This repository contains all projects that are part of the SCOTT Warehouse Sandbox as described in the SCOTT WP10. SCOTT (www.scottproject.eu) has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 737422.

The repository consists of 9 projects that use Docker images individually and are orchestrated using Docker Compose (as of now). Below is a brief summary of each project.

Warehouse Controller

Warehouse Controller (/warehousecontroller) is the entry point to the sandbox (currently).

Until the multi-objective optimisation (MOO) service is present, its implementation is stubbed via the mission.json file.

Until the Ontology server is up and serving the warehouse state, the controller fetches it from the kb.json file.

Until the Planner Reasoner is able to serve the PDDL problem file, it is generated in the generatePddlProblemFile method of the mission2plan.py file. Until the Planner Reasoner is able to serve the PDDL domain file, it is fetched from the whdomain-2.pddl file.

When the problem & domain PDDL files are ready, they are uploaded to the Metric-FF Docker service and plan generation is triggered.

👉 Start by running the Docker Compose as described in the Deployment section and running a cURL test script to trigger plan generation. Also see README.

Simulated Environment

This contains simulations required by the sandbox. It currently consists of the automated warehouse simulated in VREP with all its elements and robots. Until the multi-objective optimisation (MOO) service is present, its results should be provided by the mission.json file. Until it contains the discret event simulations for modeling the supply chain dynamics, all required information should be provided by the mission.json file.

Access to this scene (both reading and control) is currently implemented by using VREP's remoteAPI in python. This is expected to change once ROS is deployed and used for controlling the robots in the scene.

Deployment

Deployment project contains the Docker Compose configuration that allows you to start all the elements of the sandbox demo:

• Metric-FF
• Warehouse controller

👉 Start by running docker-compose up -d command inside the /deployment subdirectory and reading its README.

Metric-FF Docker

Metric-FF Docker (/ff-metric-docker) exposes Metric-FF-based planning via a RESTful service running on port 5000.

👉 Start by running the preconfigured docker-compose environment and reading project README.

Ontology server

Ontology server (/ontology-server) exposes named graphs in the Cliopatria installation over HTTP in RDF format via an Nginx server.

👉 Start by following the Getting Started section in the README.

Optic Docker

Optic Docker (/optic-docker) is a project that packages an alternative OPTIC planner via Docker.

NB! This project does not expose OPTIC via REST (yet)!

👉 Start by reading the README.

PDDL Examples

PDDL Examples (/pddl-examples) �s a folder with example PDDL files (domain and problem files), just for learning and testing purposes of the planners.

PDDL Planner - deprecated code that has been merged into Metric-FF Docker (/ff-metric-docker)

PDDL Planner (/planner) exposes PDDL planners via a REST API (so does the Metric-FF Docker, but using dockerised Metric-FF). Theoretically supports both OPTIC and Metric-FF, but only implements support for Metric-FF. Requires local installation of Metric-FF (see ff_path in plannerService.py).

👉 Start by using Metric-FF Docker and consult with Costa and Swarup if you need to touch this project.

Planner Reasoner

Planner Reasoner (/planner_reasoner) uses an internal planning ontology to transform the warehouse state (given in a form that adheres to the warehouse ontology) into the PDDL problem and domain files .

👉 Start by reading about the generate_pddl/3 predicate. A plan is generated using generate_plan/6, generate_plan/8 predicates. The plan is validated using validate_plan/8 predicate.

NB! The project is called a reasoner because it is using Prolog reasoning facilities, it does not do any reasoning over the ontology and does not produce any inferred triples (as of now).