Crowdsensing Activity Recognition using the Generic Sensor API and AWS, Hands-on Guide #4

In this tutorial, I'm going to present to you how to build a simple crowdsensing system that is capable to detect whether a user is still or is moving. I will introduce you to the Generic Sensor API that will be the main tool to retrieve the user accelerometer data. We will then analyze two different implementations: an Edge one that is capable to process the data directly from the application user, and a Cloud one that will use AWS lambda cloud processing in order to display the detection.

Overview

Crowdsensing is a technique where a large group of individuals having mobile devices capable of sensing and competing collectively share data and extract information to measure, map, analyze, estimate or infer (predict) any processes of common interest.

The tool that will let us access to the accelerometer of the user in order to detect its value is the Generic sensor API. It is a framework for exposing sensor data to the Open Web Platform in a consistent way. It does so by defining a blueprint for writing specifications of concrete sensors along with an abstract Sensor interface that can be extended to accommodate different sensor types.

The following is a useful scheme that contains system architecture:

In the picture we can see how the two sensor applications, once accessed by a user smartphone, start sending data to AWS.

We can distinguish between two different structures. One is an edge application that is capable to process and directly send data to the cloud platform. Te other one is the cloud implementation, in which the raw data is sent to the cloud without processing.

The data goes into AWS IoT Core and is directly sent to DynamoDB using an AWS IoT Rule. The lambda functions that retrieve the data for the two implementations are different. The edge data is simply retrieved from the DB and sent to the front-end. Since the cloud information has to be processed, the lambda function will process the data and send it to the dashboard stored in AWS S3 bucket.

Since the dashboard and the AWS settings for serverless implementation was already part of a previous post I made, I suggest you take a look at it in order to understand their functionalities and try to set up your own.

In this tutorial, I will just point out the differences I made in order to combine the old dashboards with the edge and cloud systems. I suggest you take a look at my repository where you will find all the code I used in this tutorial and the previous ones. You will find it here:

You can also find a useful YouTube video presenting the functionalities of the project below:

Sensor Application

For the sensor application we are going to use Node.js and set up an application locally that, once accessed by smartphone, will retrieve sensor data.

In order to use the Generic Sensor API, it is needed to set up an HTTPS connection. We will do it using OpenSSL with the following commands:

In this way we will create a new Certifications authority that will generate the Private key and the signed certificate signing request. Once we completed those steps we will be able to establish a secure connection on our localhost.

Application

Both the two implementations are very similar to what regards the web application structure. We have a server-side of the application that collects data using socket connection via the front-end script.

Server-side, we set HTTPS connection in this way:

We then use the AWS IoT SDK in order to set up a correct connection between the application and Aws IoT MQTT like this:

We will create a secure connection using the private key and the certificates,

In order to communicate via socket with the front-end and to trigger the messages we use the following lines of code:

The front-end script is differs from between the two implementations.For the cloud implementation, we can think about some really simple script that simply sends row data to the back-end:

Using LinearAccelerometerSensor we will retrieve the accelerometer values and send the raw data directly to the back-end via socket.

The image above is a picture of the payload that is sent to the AWS back-end containing the raw data.

For the edge implementation, we have to do some extra processing in order to find out if the user is still or moving.

In this way we will find out if the user is moving or still. The idea behind this algorithm is to wait 10 seconds for 10 accelerometer values. If the absolute value of this movement is more than 2 in 8 out of 10 accelerometer values than the user is probably moving. For this reason the message will contain a moving value, that will be set to true if we process a moving action.

The image above is a picture of the payload that is sent to the AWS back-end containing the processed data.

If it is needed, I suggest taking a look at the repository I linked at the beginning in order to have a more complete view of the sensor application.

Once the app is set up and running, it will send data directly to AWS IoT MQTT that will store them into the Database.

Lambda Functions

Lambda Functions are used by our implementations in order for our dashboards to be serverless. In the two cases, they always scan the database and at the end furnish the data to our front end.

The lambda functions that will be used by the two different dashboards have to retrieve two kinds of values, one for each implementation:

• The first is the last processed value
• The second is the list of the processed value produced in the last hour.

You can have a look at those functions following the GitHub link I suggested in the beginning, now let's focus on the general aspects those functions have :

• Data Fetching, we use DynamoDB client in order to communicate with the tables. in this case I decided to use the function "scan" returning all the values of the table.

• Data Output, where we pass our processed data in JSON format

• Data Processing, Here is where the real difference is, since cloud functions will have to process the data that will arrive from the sensor and the edge solution don't.

An edge solution can be represented simply as a search for the latest values:

Cloud processing instead, will have to detect whether the user is moving or not, using the same criteria presented for the edge processing web application

Once those lambda functions are set up and running we will use the API Gateway in order to take their output and use it in the dashboard.

Serverless Dashboard

Now we can create our web application in order to use those data. We will use API Gateway in order to retrieve the lambda function outputs. Since structuring the layout of the web application is not the purpose of this tutorial, I will just suggest you take a look at the repository I linked at the beginning where you can find my project and the ReactJS web application I built.

The important step I will point out is the one regarding the usage of our API calls. Once you created them, you will have access to the data produced by the lambda and you can build an application with your favorite framework and use it to display the information.

Now in order to host our public domain we will create a new S3 bucket from the S3 console. Once we gave it a name, we will upload our application build using the upload console

The Website is up and running and will have this aspect, representing the different metrics.

Conclusions

Thank you for having spent some time reading this and trying to set up your Generic Sensor API to AWS activity recognition system. This project is a part of the Fourth assignment of the Internet of Things course at Sapienza University.