Introductory video for the project
Final presentation video for the project
The need for efficient, cost-effective, and non-invasive monitoring solutions has become increasingly important in various industries. The monitoring sonar system offers a reliable and accessible solution to security and environmental concerns. This system can be used in home security, industrial safety, parking assistance, environmental monitoring, retail analytics, and traffic management. This project builds on existing technologies and offers a customizable and expandable monitoring solution for different applications.
Despite the fact that the system is mainly designed for "Home Security", it has multiple other potential applications:
This project aims to implement a monitoring system for a designated area or sector. The system employs two kinds of sensors: two ultrasonic sensors, a temperature sensor, and an actuator in the form of a servo motor, all of which are connected to a Wio Seeed Terminal, a microcontroller.
The core concept of the system involves mounting two ultrasonic sensors on top of a servo motor, which rotates the sensors to scan the designated area. These sensors transmit high-frequency sound waves and receive the corresponding echoes, thus detecting objects that are located in the vicinity of the ultrsonic sensors. The temperature sensor comes into play by measuring the temperature, which helps in calculation of the speed of sound in air.
The servo motor is responsible for continuously monitoring its position in degrees, while the ultrasonic sensors passe the distance data they has recieved (as a result of ultrasoic wave transmission and reception) to the microcontroller, the Wio Seeed Terminal, which then publishes this information over WiFi to the topic KiwiSonarData
.
To provide a user-friendly interface, the front-end utilizes SvelteJS front-end framework and other JavaScript libraries to subscribe to the topic KiwiSonarData
. Upon receiving new information, the front-end parses and displays it in the form of a radar image that showcases the range and degree of any detected object relative to the sensors.
This projetct builds a sonar using one Wio Seed Terminal (which is Arduino compatibale), two ultrasonic sensors, one temperature sensor, and one servo motor. These parts make up the hardware required to build the sonar. The hardware parts are controlled using a GUI made using SvelteJs front-end framework. The project uses the MQTT protocol (which belongs to the Publish-Subscribe architecture style ) to connect the GUI to the Wio Seeed Terminal.
The Wio Seeed Terminal is an Arduino compatibale microcontroller. This means that its manipulation is done using C++ (or C) programming language. To easily upload code on the Wio Seeed Terminal, you can use the Arduino IDE. There are libraries implemented for different sensors and also for the MQTT protocol in the SonarController directory:
KiwiServo
contains methods that are used to rotate the servo motor.KiwiSonic
contains methods that are used to manipulate the ultrasonic sensorsKiwiTemp
contains methods that are used to manipulate the temperature sensor.KiwiMQTT
contains methods that are used to manipulate the Wio Seeed Terminal to send information over the MQTT protocol.SonarController.ino
is the file containing the main code which is uploaded on the Wio Seeed Terminal. It contains the void setup()
and the void loop()
methods that are needed for the Wio to run.There is a file named KiwiSecrets_template.h
. This file is meant to keep the WiFi name and and password. When you write your WiFi name (in the ssid
attribute) and password (in the secret
attribute), you should change the name of the file from KiwiSecrets_template.h
to KiwiSecrets.h
. Note that the file KiwiSecrets.h
is put in the .gitignore
file so that the WiFi name and password are not sent to the remote repository.
You also need to download the following libraires. You can download these by clicking on the library icon in the arduino library and search the names that are mentioned below:
rpcwifi.h
is needed to connect to the WiFi. You can download it by searching for rpcwifi
.PubSubClient.h
is needed for publishing data and subscribing for data to the broker using the MQTT protocol. You can download it by searching for PubSubClient
.The following lines will explain the pin-out instructions. Use these instructions to connect the sensors to the Wio Seeed Terminal. you can use the following images for referrence to know which pin is which.
Servo motor pinout structure:
First ultrasonic sensor pinout structure:
Second ultrasoic sensor pinout structure:
Temperature sensor pinout structure.
SvelteJS was used to make the GUI for this project. In order to use SvelteJS you need to have Node.js downloaded.
The GUi initial setup was done by running the command npm create vite@latest SonarVisualizer
in the SonarVisualizer
as the directory name. However, if you use our project, you do not need to run the aforementioned command, but rather the commands mentioned next.
If you fork this project and and then pull from the remote repository, before using npm commands to upload the web page, you need to open a terminal in the SonarVisualizer
directory and run the command npm install
or npm i
. This command downloads the dependicies and packages that are used in the project.
The GUI can be run locally for testing or development purposes. This can be done by running npm run dev
in the terminal while in the SonarVisualizer
directory. After running the command, the application will be accessible at http://localhost:5173. To test the application on mobile, or other devices, it can be exposed on the local network by running npm run dev -- --host
. Following this command the application can be accessed on the local network at the local IP address of the machine it’s running on, namely at port 5173. The exact address will also be displayed in the terminal.
After installing all the required dependencies, the application can be built from source by following these steps:
SonarVisualizer
.npm run build
to compile the Svelte files and build the project.dist
subdirectory in the SonarVisualizer
directory. This command is mostly used in case you want to see if all the packages, especially the extra packages you have added to the project, can be run on the browser. Moreover, it is also used if you are planning to deploy your project on a server.If you navigate to the src
subdirectory, you can find the different components under the components
subdirectory. There is also a subdirectory called data
. This directory contains the stores.js
file which holds the information that is sent by the Wio Seeed Terminal over MQTT, and commands to be sent to the Wio Seeed Terminal by the GUI. The App.svelte
component is the root component which contains the other components that are made under the components
subdirectory.
Under components
subdirectory, there is another directory called mqtt
which conatins the MQTTHandler.svelte
component. This component contains the publish and subscribe methods needed for the MQTT to work on the GUI.
Our system, as mentioned before, made use of the MQTT protocol to create the connection between the web application and the Wio Seeed Terminal.
What is MQTT?
MQTT is a protocol that belongs to the Publish-Subscribe architecture style. The Publish-Subscribe architecture style works in the way that different components, publish the information needed by other components to a message bus (usually called the broker) under specific topics that are defined by the developers in the code. The components that need that data need to subscribe to the broker under the same topic that was used by the component(s) that published the information. The benefits of using the publish-subscribe architecture style is that there is little coupling between the componenets. Moreover, the components can work asynchronously as they can subcribe to the broker whenever they need, hence less coupling.
Now that the base of our system's architecture is explained, you can dig deeper into our project and see how our team made use of open source Publish-Subscribe libraries. Here is a component diagram that depicts the architecture of our system. Note that the broker is shown as a component, eventhough it plays the role of a connector:
As you can see in the diagram, We have two main components that communicate to each other via the broker. The App component (which is a subsystem itself), subscribes to the topic "KiwiSonarData" to receive the data that the Wio Seeed Terminal has published to the mentioned topic. The App component also publishes user's input to the KiwiSonarCommand topic. Then, the Wio Seeed Terminal subscribes to this topic and manipulates the way the sensors should work according to the user's input.
Unit tests were made for the GUI in this project. The Jest testing framework was used to make unit tests that checked the correctness of the commands sent by the GUI and the way componenets were rendered. This section contains information regarding configuring Jest on a svelte project and the commands used to run the tests. Note that when you use npm i
after forking our project and pulling from the remote repository, you can already use the testing commands on our project as Jest is already configured on it. The Jest configuration part is useful for those who want to configure Jest on their own projects.
Needed libraries:
@babel/core
, babel-jest
and @babel/preset-env
are some libraires that we used. These are needed for the transpilation that is required by Jest.svelte-jester
and jest-transform-stub
. Jest does not understand how to parse non-JavaScript files. We need to use svelte-jester
to transform Svelte files, and jest-transform-stub
for importing non-JavaScript assets (images, CSS, etc).@testing-library/svelte
(known as Svelte Testing Library) provides DOM query functions on top of Svelte in a way that encourages better testing practices. Some of the most commonly used functions are render
, getByText
, getByLabelText
, and getByRole
.@testing-library/user-event
is a companion library to Svelte Testing Library that provides more advanced simulation of browser interactions than the built-in fireEvent function. An example of this is if you need to trigger an event for a mouse click while the Ctrl key is being pressed..env
file in your code, you need to install babel-plugin-transform-vite-meta-env
to transform these variables for the commonJS module.@testing-library/jest-dom
provides a set of custom jest matchers that you can use to extend Jest. These can be used to make your tests more declarative. It has functions such as toBeDisabled()
, toBeInTheDocument()
, and toBeVisible()
.You can install the aforementioned libraires using npm:
npm install -D jest babel-jest @babel/preset-env svelte-jester jest-transform-stub @testing-library/svelte @testing-library/user-event babel-plugin-transform-vite-meta-env @testing-library/jest-dom
We need to configure Jest to transform our files. We must explicitly set our test environment to jsdom
, which we are using through Jest. Since v27 Jest’s default test environment is node, we put the configuration in a specific Jest configuration file called jest.config.json
in the project root folder (in our case in SonarVisualizer
):
{
"transform": {
"^.+\\.js$": "babel-jest",
"^.+\\.svelte$": "svelte-jester",
".+\\.(css|styl|less|sass|scss|png|jpg|ttf|woff|woff2)$": "jest-transform-stub"
},
"moduleFileExtensions": ["svelte", "js"],
"testEnvironment": "jsdom",
"setupFilesAfterEnv": ["@testing-library/jest-dom/extend-expect"]
}
We configure Babel to use the current version of node. Include the babel-plugin-transform-vite-meta-env
plugin if you are using environment variables. We put the configuration in a .babelrc
file in the project root folder (in our case in SonarVisualizer
). Babel is a free and open-source JavaScript transcompiler that is mainly used to convert ECMAScript 2015+ code into backwards-compatible JavaScript code that can be run by older JavaScript engines. It allows web developers to take advantage of the newest features of the language.
{
"presets": [["@babel/preset-env", { "targets": { "node": "current" } }]],
"plugins": ["babel-plugin-transform-vite-meta-env"]
}
Add the scripts to run the tests in your package.json
. Note that you should add them under the scripts
object.
"test": "npx jest src",
"test:watch": "npm run test -- --watch"
sources: https://www.roboleary.net/2021/11/18/svelte-app-testing-jest.html
After following the instructions (in case you are configuring Jest on your own project), you should be able to use the command npm run test
to run the tests that you have written for your project. Note that a test file should be named after the component that your are testing. For example, if you have a component called Button.svelte
then the test file should be called Button.spec.js
or Button.test.js
. As you can see, the test file has .spec.js
or .test.js
. This is needed for Jest to be able to find the test files which are written in JavaScript.
CI/CD stands for "continuous intergration" and "continuous development". We use the GitLab piplelines to continuously test code that is committed and and then deploy the code, if it passes the tests. The pipeline is written in .gitlab-ci.yml
file which is usually uploaded on the root of the project (good practice to put it there). As you have noticed by now, this is a YAML file which contains commands that are executed by the GitLab runner(s). GitLab runners are computers that have Linux as their Operating System. These runners pull your project and look for the CI file and run the commands that you have given there. To install packages and programs on the runner to run your commands, most projects (our project too) use docker images. You can find docker images for the applications (programs) that you need in order to test and/or deploy your project from docker hub. Each block of commands that is executed by the GitLab runner is called a job. Note that you need to use a runner that can handle docker images. You can see the available runners under CI/CD in settings. You can see the result of your pipline under the CI/CD Pipelines section.
You can customize your .gitlab-ci.yml
file in many ways:
rules
flag, so that your job runs only on specific branches or occations (in case of deployment, in the main
branch only). before-script
to download dependencies needed by the commands that run in the script
flag.tags
flag.script
flag. A job without the script
flag does not do anything, so it will always pass.This is just a glimpse into what you can do using CI/CD in GitLab. Our project uses CI/CD for automated testing and deployment. It is a simple pipeline. You can use this as a starting point. You can read and learn more about the sophisticated and advanced features of GitLab CI/CD here.
Kaisa Arumeel:
Alexander Säfström:
u8-mqtt.js
to vite.TrackMode.svelte
.MqttHandler.svelte
.stores.js
.Omid Khodaparast:
ScanButton.svelte
component which showcases to the end user when the start and stop commands have been received by the sonar (the Wio Seed Terminal).SonarVisualizer
directory, which contains the main application used by the end users to manipulate the sonar. .gitlab-ci.yml
and editing it by giving it different stages and different jobs to complete the automated testing and continous deployment of the project.README.md
file.Amirpooya Asadollahnejad:
ScanButton.svelte
.Range.svelte
and ScanButton.svelte
component.Sector.svelte
.Milad Tamaddondar:
WarningModal.svelte
component for the alarm and notification.NotificatonButton.svelte
component for disabling and enabling the notification and alarm feature.README.md
file.János Litkei: