Europe

The foundation for most OMiRob cases is the generic framework presented in the picture below. This is also true for our case, where the model bridges the physical execution and the scenario. The following presentation of the framework reveals, how modeling layer, scenario and execution belong to each other, where the interactions take place and what are the relevant components of the whole framework.

The basic setting for this OMiRob example use case consists of a model in ADOxx and a physical environment in the OMiLAB. The ADOxx environment is based on the SmartCity Library from the NEMO Summer School 2018, an adopted car simulation script and an example street model. A printed version of the street model, two MBots and a pedestrian make up the physical environment. Both settings are integrated via HTTP. Therefore, the model is used as a foundation for sending HTTP requests to the physical environment, which then executes the received commands.

Further details on the experiment can be found in the next section, where interactions, assumption, setups and a lot more information on the case is summarized.

A step-by-step approach was followed to conduct the integration of the CPS in the modeling environment.

1. Car-Simulation-Script: An already included car simulation script from the library was used as a basis. Firstly, it was important to find out what the script does in order to be able to adopt it for our purpose.
2. Adoption of Script: The script only uses one car. For our settings we wanted to use two cars. Therefore, the script was adopted in order to have two cars starting in parallel from different starting points.
3. Single Steps: The next step was the inclusion of choosing steps. The modeler should be able to choose whether car 1 or car 2 is the next one.  The modeler is also responsible for avoiding accidents.
4. MBot Integration: Two MBots from Makeblock are the executing CPS. They are integrated over HTTP requests conducted by the simulation script.

Interactions

The main components of the use case are the ADOxx modeling environment, that consists of the smart city library, an example model and an AdoScript for the simulation. Moreover, the CPS includes the MBots combined with raspberries. The connecting component is the Internet, that ensures the sending and receiving of http requests.

Assumptions

• two cars (MBots)
• running Tomcat on MBots
• smart city programm deployed on Tomcat
• fully charged batteries
• stable Internet connection
• one-way-streets

MBot Setup

The main parts a MBot consists of are the car itself and the connected raspberry. Additionally, sensors are plugged in to get information about the physical world and to ease the execution of commands received via HTTP. Both MBots are equipped equally.

Environment Setup

The complete physical environment consists of the two MBots, a simulated pedestrian and the street model itself. The street model was printed on normal paper. Afterwards, the elements were cut to get the correct size and glued together. In order to make the complete environment a little bit more stable, it was also fixed on the floor.

Important Webservice Commands

In the following list, the methods used by the model and sent to the cars are explained in short. There are some additional services, that are not used by the model, but rather used for support, for instance the readout of ports and similar ones.

• status: gives the distance of the ultrasonic sensor
• moveStraight: car follows the black line on the printed street model
• turnLeft: the right motor is activated to turn left until the black line on the model is available again
• turnRight: the left motor is activated to turn right until the black line on the model is available again
• jumpGap: car drives forward for a short distance to get the next street (black line)
• honk: car makes sound
• light: car shows red and blue light

Deployment

To get the MBots ready for driving and for configuration, the power for the infrastructure and the raspberry must be plugged in and the MBot must be turned on. For the deployment, a connection to the MBots was established using Putty. It is important to be connected to the OMiLAB Web for this connection. The internal IP is used to connect. Afterwards, we generated a folder on the MBots. In this folder, we installed a Tomcat and pulled our program code from git in order to deploy it on the MBots.

It is recommended to try out the MBots with the original MBlock software and a simple Bluetooth connection before, in order to find out how they move and behave. Notice that every configuration step must be done for each MBot separately. Further details you can find in the readme file located in the code repository.

Code can be found here

You can find following assets by following the link below: printable street model, Java code, adoxx scripts, adoxx library, adoxx model and a detailed readme file.

https://gitlab.dke.univie.ac.at/OMiROB/smart-city-mbot

Attention

Only a successful scenario was implemented. There is no implementation for pressing "cancel" during the selection of the next driver. However, the car is driving, although "cancel" was used. This can lead to crashing cars.

Possible future Extensions

A better decoupling of the example model would be great. Therefore, a rule engine could be implemented, which offers this possibility by evaluation of the car positions. However, this would enable a complete decoupling from the example model and its street names. Furthermore, it would be reasonable to enable the inclusion of more than two cars, in order to develop a more realistic and complex scenario.

In this section, the results can be seen in a short example video. The film reveals the interactions between modelers and model, as well as the actions in the physical environment. Both - model and physical environment are executed in parallel. Only a simple successful scenario execution is shown in the video. For sure, there are much more possibilities to move the cars through the street model.