BeagleBone Black - Communication and Modularity

Introduction

This project is a proof of concept to use the Beaglebone Black shield to work as a modular structure using different protocols such as TCP, UDP, COAP and MQTT programmed using C++ and a Ubidots MQTT server broker.

Main system schema

In the image, we can see how the project works as a hierarchical structure where each module has a unique purpose:

SENSORS_INFO NODE

Working as a main producer, is in charge to obtain all the data from the sensors, parse it in a local common structure and send it (via COAP protocol) to the upper level.

Until today, It only has Temperature and Humidity measurements, but it should be easy to add more.

As a personal requirement, It has 3 options to get a measurement:

• BeagleBone. Sinusoidal discrete (continuous with retention) function with an amplitude and frequency given (result wave not verify. Just to test the system if hardware is not available).

• Arduino: Sinusoidal continuous function with an amplitude and frequency given (result wave not verify. Just to test the system if hardware is not available). The communication between the Arduino and the BeagleBone is by Serial and sending a common data structure. Note that Arduino has a different byte precision to represent some types (e.g. 4 vs 8 bytes using Double type).

• DHT111: Real sensor to get the environment measurement.

All modes are running at the same time, by using a simple semaphore, only one produces the Temperature and Humidity measurement. Using the COAP protocol, SENSORS_INFO update every X time its working mode.

SENSORS_SWITCH NODE

In case of a user event has to be propagated, this node is designed to englobe digital and analog data using simple switches and potentiometers.

The image above shows the schema about how this node works. The buttons are implemented using asynchronous events and the potentiometer with a polling strategy. Once new data is generated, It is packed in a global data structure and send it over UDP to the Gateway node.

Potentiometer current value is sent only every X time or if difference is bigger than X.

Actuators Node

Once the data is obtained from the environment or from the user, now it's time to explain the specific node to use it or to show any kind of feedback. As the simplest way, the system uses some leds and a servomotor.

The Red/Orange/Green led purpose is to show in witch mode is the SENSORS_INFO node working. The servomotor shows the status of the potentiometer value and the Alarm led is to show if this value is higher than X.

The functionality of these implementations can be other, we just have to change witch data is sent to the ACTUATORS node in the Ubidots rules.

Gateway node

It supposes the main node of the project as it manages all the connections with the lowest levels and with the Ubidots MQTT server broker.

To solve the particular problem about how to move the data regardless of the communication protocol, a global common data structure is established. So, each node (producer or consumer) has to adapt the data for a better understanding in the whole system. Only the GATEWAY has to know how to send or extract the data from the MQTT server because, in this project, it is supposed to implement the "public" access or the "gateway" to the system.

The gateway maintains the COAP, UDP and TCP servers to talk with the lowest level and, at the same time, uses the MQTT protocol to publish the received data to the Ubidots server. In the same scenario, it is subscribed to some variables (e.g. alarm, state, led_status) to inform all the nodes about any changes. Note that a Internet connection is important to keep a coherent status for all the system, for this reason is possible to compile the project to establish a direct data redirection from the producers to the consumers (as the picture shows).

General vision

Now, we can appreciate a schema about how data moves from the connection servers to the MQTT client.

When a server receives new data, it has to convert it to the global structure if proceed and execute data_management function where depending the data (the structure contain all the necessary information) it is redirected to Ubidots, transformed as intern data or just used to update the server information.

In the picture, all 3 servers are implemented using Threads (only TCP server is multi-thread) to keep all the time the connection alive and increase the performance of the whole system due to there are no global variables or shared memory.

Ubidots

As a MQTT broker, maintains all the information about the environment sensors or the potentiometer value. It has the possibility to redirect the data to the subscribers or to establish events that change a variable value or send an alert to the users.

In the picture below, the data is redirected using Ubidots rules to modify led_status and alarm variable:

But one of the coolest tools availables in Ubidots is the data visualisation:

Conclusions

As a final part of this little explanation the system will look like this:

Now, I'm glad to say that this proof of concept project is done. I have gained a huge amount of experience with communication protocols and data management as well as using the Beaglebone Black hardware.

Please, feel free to implement this project at your home and, of course, improve it :).

Copyright information

This project is under GNU General Public License version 3 or later (GPL3+) but some parts was taken from other people. Please, see its respective copyright permissions:

• MQTT client library: eclipse/paho.mqtt.c

• COAP library: staropram/cantcoap

• Rapidjson library: Tencent/rapidjson

• Arduino DHT111 code: Adafruit

• Some BeagleBone HALs and monitor library in SENSORS_INFO:

Author: Jose Simo. Universitat Politecnica de Valencia. AI2-DISCA. Creative Commons.

Other

You can see a little presentation here. [Available in Spanish]