Dezyne is a model-driven software engineering tool that enables software engineers to create, explore and formally verify designs for state-based, event-driven or concurrent software systems. It generates code that is robust, reliable and trustworthy. Dezyne gives software engineers the ability to fully explore their designs using advanced simulation techniques. Automated formal verification discovers hidden defects that are otherwise practically impossible to find.
Lego Mindstorm Model
Verum uses a Lego Mindstorms model as a live demonstrator of results achieved with the Dezyne modelling tool. This is a model of a wafer stepper composed of a feeder robot, a 2d stage and a material handling robot. The control software is mainly written with Dezyne tool. It interfaces with the motors and sensors through USB connection with four Mindstorm controller bricks. The overall system view of the Lego Mindstorm model is shown in Figure 1.
Goal of the Project
The assignment is to use the existing model to show new features in the dezyne modelling language (i.e.) dealing with multiprocessing. The goal of the project is to distribute the controller across various Raspberry Pi’s as shown in Figure 2 (i.e.) to replace the Mindstorm controller bricks with the Raspberry Pi.
This project is carried out in several steps. Each step is explained in detail.
Step 1: Identifying subsystem of Lego Mindstorm
The first step is to analyze the existing design of Lego Mindstorm models to support the distributed multiprocessor design. We have identified four subsystems in the existing model. The four subsystems are listed below and each of these subsystems are marked in Figure 3.
This subsystem is used to control the material handling robot and it is also associated with the overall control of the Lego Mindstorm system.
This subsystem controls the 2d stage (i.e.) It is responsible for the movement of balls inside the stage. It also does the function of colour measurement of the ball.
This subsystem controls the feeder robot (i.e.) It is responsible for feeding of balls into the Lego system.
This subsystem controls the output stage where balls are sorted according to their respective colour.
Step 2: Controlling Lego Motors using BrickPi
The second step is to find an appropriate way to control the Lego motors and sensors using Raspberry Pi. We decided to use BrickPi to control the Lego motors and sensors. BrickPi is a robot kit that can connect the Lego Mindstorm sensors and motors to the Raspberry Pi. The BrickPi is a Raspberry Pi add-on which stacks on top of the Raspberry Pi and accepts Lego Mindstorm motors and sensors. The Raspberry Pi and BrickPi communicate through SPI. The Raspberry Pi act as a master, writing to and reading from BrickPi whereas the BrickPi acts as a slave - receiving from and replying to the Raspberry Pi.
We have implemented each of these subsystems on individual Raspberry Pi’s and verified the functionality of these subsystems.
Step 3: Communication protocol to support concurrent process
The next step is to find the appropriate communication protocol to support multi-processing. We have decided to use the zeromq communication protocol due to its extensive support to multithreading. In particular, we used zeromq polling function. It allows two different subsystems to connect in a peer to peer manner. The zeromq polling function provides a mechanism for applications to multiplex input/output events in a level-triggered fashion over a set of sockets.
For Lego Mindstorm application, we configure the subsystem which provides the interface to be server and the subsystem which requires the interface to be client.
Step 4: Integration of zeromq communication protocol with the Lego Mindstorm Model Subsystem
The final step is to integrate the zeromq communication protocol into the Lego subsystem. All the subsystems communicates with each other using zeromq. Let us consider a case, where the MaterialHandler subsystem requires an interface (Convey) from the conveyor subsystem. These subsystems are connected directly through the interface in the existing model. Now we decouple the subsystem MaterialHandler and Conveyor and these subsystems run concurrently on two different Raspberry Pi’s. The interface Convey is communicated through Zeromq. The conveyor subsystem acts as a server and the MaterialHandler subsytem acts as a client. This case is illustrated in Figure 4.
In the same way, all the subsystems are decoupled from the system. These subsystems are now implemented and controlled using Raspberry Pi through BrickPi. In all of them, MaterialHandler acts as a client.
Extension to Lego Model: A Switch
A switch(Touch Sensor) is added to the Feeder subsytem to control the Lego. The switch is modelled in such a way that when it is pressed for the first time, it starts calibrating all the systems in lego. After calibrating, it automatically starts to sort the ball. If the switch is pressed while sorting the ball/calibrating, it will stop its current operation(i.e Switch press now acts as a stop. When the switch is pressed once again, Lego system will start calibrating.) When the switch is pressed after ball sorting, the lego system starts to sort the ball once again.
It is wise to implement in the Material handler, because it is the master controller. But I implemented the switch control in feeder, because Brickpi of Materialhandler subsystem does not have a free port.
Each subsystem is modelled in Dezyne and is proven to be correct. Each of the subsystems now have a dedicated controller and use an inter-process zeromq communication mechanism to interact with other subsystems. The total system is now integrated in the Lego system. Figure 5 shows the distributed controller implemented in the Lego Mindstorm models.