Final task ISS-2021 Bologna: Automated Car-Parking

Conceptual architecture of the system

The computational nodes

For this deployment on a testing environment, we decided to split the actors into two contexts. The context with the business logic and the main components of the system is to be run on a PC. The other is to be run on a Raspberry Pi attached to a real sonar device. The two Web GUIs and the BasicRobot remain independent and may be arbitrarily split between the two PCs.

The Web GUIs

The Web GUIs are put on two different Spring servers on port 8100 and port 8101 and are built into distributable tarballs via Gradle.

gradlew -b build.gradle.kts distTar

The Docker images of the Web GUIs are created by a simple Dockerfile.

FROM openjdk:8-jre-alpine
EXPOSE 8101
ADD ./build/distributions/*.tar /
WORKDIR /carparking.webgui-1.0/bin
CMD ["sh", "carparking.webgui"]

# docker build --rm -t client-carparking-webgui .
# docker save -o client_carparking_webgui.tar client-carparking-webgui
# docker load -i client_carparking_webgui.tar

Since they are deployed on the same node, we can leverage a single YAML file to execute them.

services:
  client:
  image: client-carparking-webgui
  ports:
    - 8100:8100
  manager:
  image: manager-carparking-webgui
  ports:
    - 8101:8101

# docker-compose -f carparking_webgui.yaml up

The QAK contexts

A real sonar device has been connected to the Raspberry Pi to carry out the function of the presence sensor in the OUTDOOR. At the hardware level, the connections are as follows:

Since the difficulty to make WiringPi work with Docker, we decided to distribute the QAK contexts as ZIP packages built with a Gradle script which also includes all the additional required files.

distZip {
  into(project.name+"-1.0/bin") {
    from '.'
    include 'sonar.c'
    include 'sonar'
    include '*.pl'
    include 'parkingMap.bin'
    include 'parkingMap.txt'
    include 'Californium.properties'
  }
}

# gradle -b build2021.gradle distZip

We created a testing file as requested by the client, assuming that the temperature is and remains ok, the fan is off, INDOOR and OUTDOOR are free and some parking slots are occupied since the beginning. We need to simulate on the system an enter request, a carenter and a pick up request, at a distance of 2 seconds from each other.

a. Enter request

1. The business logic automaton enters the acceptIN state and requests to known the INDOOR state from the sensorsbrokeractor.
2. The sensorsbrokeractor replies that the INDOOR is free, and the business logic switches to the informIN state.
3. The business logic checks the slotnum and sends it to the customer gui.

b. Carenter

1. When it receives the carenter request, the business logic goes to the moveToIn state and commands the trolley to go to INDOOR.
2. The trolley checks the position of the INDOOR and asks the directional planner to calculate the route.
3. The trolley then changes its state from idle to working and performs the moves given by the directional planner until it receives a null move.
4. The trolley communicates the termination of the movement to the business logic, which passes to the receipt state.
5. The business logic generates a tokenid, associates it with the previously calculated slotnum and communicates it to the client.
6. The business logic switches to the moveToSlotIn state, communicates the slot occupation to the manager's gui and requests the trolley (as already described) to go to the correct parking slot.
7. When the trolley finishes its movement, the business logic switches to the moveToHome state and requests the trolley (which enters the idle state) to go to the home position.

c. Pick up request

1. Before the trolley returns home, the business logic receives the exit request and goes into the acceptOUT state.
2. The business logic compares the received tokenid with the registered ones, determines the slotnum and requests the OUTDOOR status from the sensorsbrokeractor.
3. The sensorsbrokeractor replies that the OUTDOOR is free and the business logic notifies the client gui that the request has been accepted.
4. The business logic passes to the moveToSlotOut state and commands the trolley (as previously described) to go to the parking slot associated with the calculated slotnum, passing to status working.
5. When the trolley reaches the position, the business logic goes to the moveToOut state, records the release of the parking slot (communicating it to the manager's gui) and requests the trolley to go to the OUTDOOR.
6. Once the OUTDOOR is reached, the business logic switches to the moveToHome state and asks the trolley (now in idle state) to go to the home position.