Azure Sphere Home Process Controller

This project was created for Home Is Where the Hack Is Challenge, with Avnet Azure Sphere and has won Grand Prize. For original blog post click here

This project is an implementation of multipurpose industrial controller adapted for home IoT systems, smart home services and assistants and also can be easily tuned and expanded if necessary. As base, the project uses Azure Sphere starter kit with FreeRTOS on RT capable core.

Preface

Before I start with the project, I decided to conduct a brief introduction describing what process control is. In industrial process control this means bringing the dynamic object to a certain state and maintain this state as accurately as possible. It is know that actuators are not perfect and e.g the motor on which we give 12 volts will spin differently depending on the load connected to the shaft. This is where process controllers come into action. The task of the controller is to give some output value that will minimize the difference (the error) between out setpoint value and real value (process value). Going back to the example of an motor, let’s assume that we would want to control the angular velocity of the shaft. In this case our setpoint is the angular velocity that we want to keep on the shaft no matter the load, the process value it real angular velocity received from some sensor, e.g rotary encoder and our control value is the voltage that is being feed to the motor e.g 0-12V and our error is the difference that we want to minimize and keep at 0 if possible. The most popular control loop is shown below.

There is a lot of different controllers available in the industry, varying in size, computing power, accuracy and control possibilities but the most popular regulators can be divided into two categories: Continuous and discrete. Continuous regulators are always active and constantly process the error value and are trying to minimize it by increasing or decreasing control output. Their output can take all the values between minimal and maximal control value. The discrete controllers can output only limited number of control values. The most standard example of discrete control is the self-describing two state controller. When error value is below some point, the two state controller turns on actuator and keeps it on until error exceeds some other point and then actuator is turned off. As you have guessed, this type of controller doesn’t really minimize the error but keeps it oscillating between some two values. Its easy tune and for some slow processes good enough. Also, if the actuator has only two available states (e.g home boiler has on/off states) it is necessary to have only two state control as it is not possible to keep continuous control on it.

This project is an implementation of multipurpose industrial controller adapted for home IoT systems, smart home services and assistants andalso can be easily tuned and expanded if necessary.

In home there is a lot of potential for closed loop control systems e.g:

• Gardening
• Brewing
• Wildlife preserving
• Convenience

General assumptions and concepts

The controller

The basis of the project is as the name implies – is the regulator itself. In order to not limit the usage of the project I’ve decided to implemented both continuous and discrete controllers. As the continuous controller I’ve chosen PID controller and as discrete – two state controller. The controller shall be selected from configuration website hosted on the device itself. As the control algorithm is a critical task that requires precision timing and time determinism It was decided to implement it within real time capable core of the Azure Sphere along with all GPIO communication such as communication with sensors and actuators, additional EEPROM memory, 7 segment display, buttons and diodes. The high level core will be responsible for communication with virtual world such as Azure Cloud, IoT devices via MQTT broker and through HTTP server that serves easy access to all of the configuration parameters of the device.

Expansion cards

In order to ensure the largest possible number of supported objects, measurements and actuation were decided to be read from/written to specially designed expansion cards. Thanks to these cards it is possible to control virtually any linear object as long as there is right expansion card for it. To ensure safety of the control process, it was decided to design these cards as separate devices with separate microcontrollers. Thanks to this, communication between the controller and cards could be secured from potential errors and noise with checksum and additional confirmation bits. This method can also be used to check whether cards are connected and are working properly. In case of the card’s fault, the controller goes into failure state and tries to write lowest possible control value into output card. This state can be cleared only by performing hard reset.

The operator’s panel

The panel (in front of a device) will enable user to check device's IP address and current setpoint via 7 segment display, check control’s error via led bar and check whether there any errors through three error diodes: expansion card’s failure, MQTT not connected and network’s error.

Setpoint setting

To maximize the usability of the project it was decided to let user change the setpoint from three places: MQTT, configuration website and by using the potentiometer located on the housing.

General concept of the device is visible on the diagram below.

MQTT

Nowdays, MQTT can be considered as one of the most popular protocols for communication in home IoT networks. The protocol is used by most popular DIY devices on the market such as those based on ESP8266 and is used to integrate devices with popular home automation services such as Home Assistant and Domoticz. In the project, the controller publishes every 10 seconds the setpoint and proces values to MQTT broker user defined topics and also subscribes setpoint topic for incoming setpoint changes. Use of MQTT lets users who are more experienced with proces control to use these values for coordination with other devices or for supervisory control (e.g optimization algorithms). The controller uses QoS 1 standard of MQTT messaging protocol.

Connectivity

Due to the fact that Azure Sphere does not have a hotspot functionality yet, the connection to the device was decided to be initiated through a hotspot shared from smartphone. By default, the controller tries to connect AzCon network with a password: 12345678. After sharing a hotspot from a smartphone with such parameters the controller will connect to it and it will be possible to obtain it’s local ip address through operator’s panel. Thanks to this it will be possible to access device’s configuration website (local_ip:8181/config) and from it it will be possible to enter our WiFi credentials. After this procedurę, to protect the controller against tampering and increase it’s security (after disconnecting from the main network it will try to connect to AzCon again) the AzCon’s password is changed to the same one that was used when connecting to user’s network. Thanks to this operation, no unauthorized person will be able to take over the controller during the absence of the main network.

Fail safe behavior

To avoid problems that may occur in the event of a power outage, it was decided to add to the project a non-volatile memory that will be used to store the most important controller data such as controller’s configuration, MQTT configuration and informations about expansion cards.

Azure Cloud

Due to the „down to earth” character of the project, it was decided to send to the cloud only informations about the setpoint and proces value.

Electronic designs

In order to not play with breadboards, it was decided to make a durable, solid project using toner transfer method. All of the boards were designed in KiCad program.

Main board

The schematic above shows the controller’s main board. There are two 5V voltage regulators, one for Azure Sphere itself and one for expansion cards. The board also contains 1kb EEPROM memory for configuration, two SIPO registers to control led bar and status diodes, and connectors for buttons, diodes, 7 segment display and potentiometer.

Control panel

The panel has an led bar showing current control error, leds signaling status of the device and buttons responsible for setpoint setting and displaying device’s ip addres to user so configuration website can be accessed.

Input peripheral board

As an input, It was decided to use distance measurement from HC-SR04 ultrasonic sensor. In order to measure and secure data Arduino Nano was used. The SPI MISO goes to the motherboard via a voltage divider due to differences in voltage levels between Arduino and Azure Sphere.

Output peripheral board

Similar to the input expansion card, the output card is equipped with Arduino Nano but this time it controls the NMOS transistor via PWM.

Housing

The housing of the project was made on a 3D printer. The main assumption was the possibility of placing the controller on a DIN rail (TH35) together with modular equipment. The housing was decided, just like the electronics, to be divided into 3 parts: input/output expansion card's housings and main board’s housing.

Electronics boards connected to the back of the housings:

Separate housing designs:

Complete housing with expansion cards connected:

Back of the controller (DIN mounts created by https://www.thingiverse.com/RobertHunt/about (https://www.thingiverse.com/thing:101024)):

High level core

As described in General concepts, the main task of this core will be communication with virtual world. For this purpose, 2 timers were prepared that are responsible for periodical data transmission to MQTT and the Azure cloud. In addition, 2 callback functions were written that are responsible for receiving the setpoint value from MQTT topic and for GET request processing from HTTP server. In order to communicate with the real time core, the sample code from Azure’s repository was used (https://github.com/Azure/azure-sphere-samples/tree/master/Samples/IntercoreComms). Data transfer between cores is based on the master-slave principle, where the master is a high-level core that sends a frame containing the command and data. After frame has been sent from the master, it waits for a response from slave real time capable core. For simple commands, RT core responds with simple “ok”, in other cases it responds with data requested by high level core.

Web based configuration

In order to allow the user to configure the device, it was decided to provide a simple website at local_ip:8181/config. For this purpose a simple socket based HTTP server has been written which awaits in a separate thread for connections with clients:

After connection, callback (siteGETCallback) is calles, in which, depending on the requested page’s location, the configuration website is provided, or a 404 error.

The configuration website is shown below:

Integration with home automation systems via MQTT

For communication with MQTT, a third party library was used (https://github.com/LiamBindle/MQTT-C) which works without any problems on Azure Sphere. To use this library, a wrapper header has been written to simplify the structure of the main code. As with HTTP server, the main MQTT loop runs on a separate thread:

And also has a callback that is called when a message is received from setpoint’s thread:

Cloud based control reporting

In the project, the cloud plays the role of supervisory panel in which current state of the control process can be seen. Every minute telemetry about current setpoint and process value is being sent to the cloud and both values are displayed on time plot.

In the picture above, you can see setpoint changes made with knob over time. Input sensor was disconnected at the time so chart of process value is always 0.

Real time core

In order to control individual components of the real time core, it was decided to use the real time operating system (RTOS).

FreeRTOS

As the operatins system that manages all of GPIO communication, it was decided to use the well-known FreeRTOS. The use of a dedicated system will decompose individual task of the interface control and communication into simple and readable tasks. It will also provide time determinism required for PID control. the FreeRTOS version along with HAL library for Azure Sphere was obtained from: https://github.com/MediaTek-Labs/mt3620_m4_software.

UI Tasks

In order to control events from the operator panel, it was decided to use 4 tasks responsible for individual panel components:

• Button task – responsible for reacting on press events on the SP and IP buttons,
• Display task – responsible for displaying current setpoint, knob’s value or IP address depending on the global state of the RT core,
• LED task – responsible for controlling the led bar and LEDs signaling operation of the device,
• Knob task – responsible for reacting to a value change on the knob.

Communication with peripheral boards

It was decided to perform communication with the expansion cards through software SPI. While there is hardware SPI available on the board, it has been tested that for some reason it does not work with wifi and debug UART in use (this might be a defect in my board). The communication was decided to be divided into 2 algorithms: The first one that is used to read the input value, in which bytes of data and CRC are received. In the case of CRC error, the error counter is increased. When the counter reaches 10 errors in a row, the controller enters failure state. If the transaction is error free, then the counter is zeroed. Outputs are written in such way that a frame with CRC is sent to output expansion card and a byte with the result of the transaction is received in the next control cycle. In case when this byte is set to 1, the transaction was successful. In other cases, the transaction is considered erroneous and the error counter is increased. If the cards are disconnected from the controller, the transactions are automatically considered to be incorrect (due to incorrect CRC for inputs and incorrect transaction result byte for outputs).

Control algorithm task

A separate and the most important task from the project’s perspective is the task responsible for process control. In this task it was decided to use methodology known from PLCs in which the input is read first, then control algorithm is performed, then outputs are written. While it is possible to simultaneously read inputs and write outputs via SPI full duplex, it will introduce delays by sample for input or output card which is not a good solution from control engineering's perspective.

Mailbox task

Communication with high level core was decided to be obtained using separate task. This task executes all processes that have been assigned to the process queue by interrupts resulting from the incoming data provided by high level core.

External EEPROM memory

Communication with EEPROM memory is performed using I2C. Communication occurs at the request of one of the working tasks and is a synchronous procedure. The memory stores information about selected control algorithm, information about inputs/outputs and information about MQTT broker.

Realization of the board

Boards etched and ready to be drilled:

Main board with operator’s panel ready to be assembled:

Assembled main board:

All the stuff connected and first test with external 12V voltage:

First tests of expansion cards on breadboards:

Expansion cards etched and soldered:

Complete electronic design on DIN rail, programming and bug fixing in progress:

Completed controller:

Tests

Both tests were performed using MQTT script similar to script shown in one of the videos above. In the script setpoint's value is changed roughly every 7 minutes. The script changes the setpoint from 50 to 100 to 50 in increments of 15. Setpoint and process value were recorded using mosquitto MQTT broker.

Two state control

In the plot above you can see that two state control works and keeps value roughly around setpoint. But also you can see that the value oscillates around it (+/- 3 milimeters). This controller is ideal for slow processes or processes where some small error does not matter that much. In the project, following parameters were configured for two state controller:

• Max top error value: 2mm
• Max bottom error value: 2mm
• On value of the actuator: 12V
• Off value of the actuator: 0V

PID control

As you can see, PID control works a lot better than two state control. It keeps process value pretty much on setpoint's location. On the plot one problem can be seen: the sensor is a bit noisy and it can affect our control mechanism. In the project, following parameters were configured for PID controller controller:

• kp:20
• ki: 10
• kd: 0
• Lower CV saturation: 0
• Upper CV saturation: 12V

Longer test:

Instructions how to recreate the controller

Electronics

• Simply etch the boards and solder all of the components based on provided schematics. Start with jumpers, then bigger elements.
• Solder female 2x1 connector into +5V header of Azure Sphere board
• Connect Azure Sphere board to the main board
• Solder some cables directly to the operator panel’s diodes, led bar and buttons and secure connections with hot glue (lazy way but ech)
• Connect operator’s panel to main board as in provided schematics
• Connect Arduino’s to already soldered expansion boards
• Connect expansion boards to main board

The code

• In azsphere shell add two networks to the board: "azsphere dev wifi add –ssid AzCon –psk 12345678" and "azsphere dev wifi add –ssid USER_NET –psk 12345678"
• Install Git
• Create directory for the project
• Inside project's directory perform these commands:
• git init
• git remote add origin https://github.com/Tai-Min/Azure-Sphere-Home-Process-Controller
• git pull origin master
• git submodule update –init –recursive
• Open the project in Visual Studio
• Upload RT Core
• Upload HL Core
• Download and insert following library inside Arduino’s "libraries" folder: https://github.com/Martinsos/arduino-lib-hc-sr04
• Change line in HCSR04.cpp from “unsigned long durationMicroSec = pulseIn(echoPin, HIGH);” to “unsigned long durationMicroSec = pulseIn(echoPin, HIGH, 30000);”
• Upload codes to expansion boards using Arduino IDE
• For Azure IoT Cental see: https://github.com/Azure/azure-sphere-samples/blob/master/Samples/AzureIoT/IoTCentral.md
• In Azure IoT Central, in Device Templates add new template, then new interface with “Setpoint” and “Process value” possibilities
• When you connect your device to a WiFi, in Azure IoT Central it should show under Devices, migrate device into your device template

Housing

• 3D print all stl files available in project’s repository with 0.2mm layer size, 20% infill and supports
• Assembly main board on adapter (black part on photos)
• 3D print DIN rail mounts (01 ver) from here: https://www.thingiverse.com/thing:101024
• Connect DIN mounts to the backs of the printed housings
• Connect boards to the back of the hounsings, main board via screws and nuts, expansion boards just clicks inside.
• Screw top parts of the housings via 3mm screws, no nuts needed