Author: akselnladegaard

Day 5: Thursday – Stepper motor and NodeRED

akselnladegaardLeave a comment

Aksel, my focus has been upon: creating an Arduino function for the mixers’ stepper motor, designing another dough mixing hook, helping with NodeRED and other miscellaneous things.

The function accepts 2 values, a mixing degree (how much to turn away from neutral) and a speed between 0-100%
E.g the stepper motor turns 45 degrees forward, then -90 degrees and then 45 degrees again. This returns it to the initial steps and it’s now ready for the next mixing cycle.
Our stepper motor is a 17hs4401 bi-channel which is rated for 1.7A and we drive it with an easydriver which can deliver 0.75A per channel. This results in a 1.5A current.
We had to turn the Easydriver up to its max to reduce the risk of it ‘stepping wrong’ in high viscosity doughs. This is however a problem that can be mitigated with the proper gearing and potentialy a more powerfull motor in the final product.

Node Red

We also worked further on the Node Red coding. We choose that we wanted the node to communicate the mode/setting, and a few other thing needed to control the modes, but other than this most of the coding and the functions will be done in Arduino.

The dashboard has 4 main functions. The first one is to display information from the sourdough machine, this will show information that the user needs. The next one is to start up a new sourdough. This will send a message to the NodeMCU via the MQTT to start the mode called Start-up. This mode will check if the sourdough contianer is empty, check if the flour and water container is filled, and then mix the water and flour to start up a sourdough from scratch. The Start-up mode will end after 3 days, where NodeRED will send the message to set the mode to Keep it kicking (standart mode). In Baking mode the user types in the amount of dough needed in their recipe and which day they want to bake. Baking mode will feed the dough the appropriate amount, to make sure that the amount of dough needed is ready on the right day, and that there is also some sourdough left, to keep it going. After baking NodeRED will set the mode to Keep it Kicking again. The last function is travel mode. Here the user will type in how many days they will be gone for and press OK. NodeRED, will send the message to NodeMCU to start up the travel mode. When travel mode is started the user will be asked to remove some of the sourdough, and the machine will check if the flour and water containers are completely filled. Then the machine will keep feeding the dough a smaller amount of flour and water everyday, increasing the amount as the weeks go by, and after the set amount of travel days, the mode will be changed back to Keep it Kicking.

Day 3: Tuesday – The sourdough mixing chamber

akselnladegaardLeave a comment

Today has been focusing around detailing the essential parts for the MVP.
Designing the concept and detailing the geometry requirements has been the one of the tasks for Aksel, Ruben and Sebastian this Tuesday

The mixing chamber has a lot of requirements and is one of the essential parts of the apparatus. This is the most frequently used part of the machine, thus it has to afford easy use.

The rough concept for the sourdough container / mixing chamber

The vision: the user can at any point easily pull out the chamber and pour out the desired amount of sourdough and place it back. The entire thing is easy to wash and easy to know dose and keep the minimum amount of dough in the container. †

The mixing is done by turning the dough hook axle between -45 to 45 degrees, and potentially higher as the dough increases in size, thereby saving energy whilst mixing the entire dough.

The dough mixer

The shaft easily snaps into the container and can only face one way; it can however sit whatever way in the container. We chose this as it allows the user to have the handle in whichever side that fits their kitchen, whilst only being insertable that way.

As the dough hook is always in the container, thus making it easy to clean the entire container; even though it’s hopefully an uncommon event.

If the user wishes to mix the sourdough further then they are able to by turning the dough hook axle with their hands.

When removing dough there are several options depending on the dough consistency. If the dough is very liquid, then it can be poured using the containers designated pouring tip.

If the dough has gotten a high viscousity it can be desirable to use a spoon or whatever other tool. In this case can snap it out the axle and lay it in the creaveses on the left side of container, whilst keeping the hooks submerged. This avoids spillage when removing dough and even keeps them in whilst pouring.

The sourdough container

The container will consists of a somewhat halfcircle with a round foot, a pouring tip in the one side, snap fit ‘bearings’ for the dough mixer and a handle. On both sides are there measurements, displaying a minimum amount of sour dough to keep and mL/dL. The round foot is also used for guiding the container using a simple channel system. This is to ensure a smooth connection between the dough mixing axle and the motor.

The exact geometry of the dough hooks is yet to be determined, we have had one prototype was not suitable for high viscosity doughs, it wasn’t too pretty either. Therefore have Aksel and Ruben created a prototype which will be tested tomorrow hopefully with the stepper motor. Early tests were conducted turning the dough mixer manually, which is not as representative of the real world as is desirable. This stage might be pushed later into the project as it is easier to optimize when the MVP is done.

Project 2: IoT Safe, final overview

akselnladegaardLeave a comment
  1. Introduction
  2. Electric circuit
  3. Dashboard and Node-RED
  4. Buzzer + OLED
  5. The locker

The goal of this projet has been to create a single IoT safe that can be unlocked via a web-browser. We have achieved this by using a node MCU, Node-RED hosted on IBM cloud, using CloudMQQT as our broker and various other hardware components.

The Node-MCU, acts as the hardware controller. It’s code defines its functions but it is at no point in control over the safe, the Node-RED is in charge of what the safe does. This makes it easy to adapt the hardware part of this project to a completely different IoT safe experience.

All Node-MCU functions are triggered via strings over the broker, from Node-RED: Ie. we can play specific buzzer sounds by sending either “success” or “failure”.

The project can be seen as a proof of concept, as it only accounts for one safe. It would require a database to have multiple safes running over one flow. Ideally one could have multiple safes running over one Node-MCU or one central server handling it. Another possibility is just accepting the higher safe costs and each safe running on its own cloud instance, own Node-MCU and so forth.

2. Electric circuit

The electric circuit and components can be analysed via the schematic seen below.

Power Supply:
Our Node-MCU is powered form 12 volt direct current outputted by an adapter. It transforms 220 voltage alternating current from a standard house power plug. This way the locker can be be powered from any outlet. Same adapter delivers power to the solenoid motor inside the electronic lock.

The powered Node-MCU delivers 3 volts direct current to the OLED and the buzzer is powered by the digital output pin D0.

3. Dashboard

The Dashboard, or UI (user interface), is an important facette of the product. It’s the digital front end and it must guide the user. The UI consists of 3 elements.

A presentation element welcomes the user and displays the locker’s status (Available / Occupied). This is connected to the OLED that will also display OLED.

An ‘Unlock’ element asks for passcode. In case the user has already registered with a passcode he/she must enter the code and the closet will automatically unlock. Entering a passcode without registering will display the messages: “Please sign up to use the locker” and if it is in use and the passcode is incorrect: “Wrong password, thief”.

Lastly: The register element. This is where you type your email and passcode. Registering will send the user an email with instructions on how to use the locker along with a link to the UI and the registered password (in case you forget).

The confirmation mail looks as such:

4. Buzzer & OLED

OLED screen

The OLED is located behind a acrylic plate, to give the locker a nicer finish and make the screen look better. The acrylic plate makes the screen more appenrent and it lights up more.

The buzzer is located behind the airholes made to let sounds pass through.

The hole in the buzzer is locate behinde one of the holes, this make the sound go though better. The rest of the holes if for the look of the locker.

5. The locker

We are signing in with e-mail and password, and the locker opens as it should, playing the right tone
An incorrect password played the FAIL-melody.
The correct password opened the locker playing the SUCCESS-melody.
The final Locker

The final locker will open when the user signs up, and it opens again when the user types in their password. The lock is mounted on the wall in Skylab and is fully functional.

The final Node-RED logic sprint – week 6

akselnladegaardLeave a comment

By: Aksel N. Ladegaard and Sebastian Mc. Aleer

Aksel:

Today has been the last sprint in finishing the cloud based logic for the IoT Safe. I’d just like to offer a quick overview of the methodology of solving this task and why we chose the solutions we did.

The assignment requirement was 1 safe, which means there isn’t need for a database (which we haven’t been taught about yet) so we have done all dependent on flow variables.

The whole flow is initially triggered by 1 of 2 things:

  1. Registering a new user
  2. Unlocking the safe

The administrator of the safe has the option of doing a few more things:

  1. Manually injecting MQTT commands through the interface on cloudmqtt, which is the broker that we use
  2. Manually reset it through nodeRed, where we have made an admin reset button (inject)

The safe is constantly governed by a few flow variables which are set in nodeRed over mqtt, these variables are:

  1. Safe
  2. Lockerstate
  3. Password
  4. Email

Safe, can be one of three values: undefined, available & inUse. Depending on this we can check whether the safe is ready for registering a new user, unlocking and so forth.

Lockerstate is initiated from the nodeMcu which changes everytime the lock solenoid is triggered. This is only triggered for around 100ms, so it immediately sends a message over the broker and the flow variable is set in a function node.
This is essential as to detect when the safe is just closed and in use. This can be detected with 2 switches (ie. if else statements).
First one checking the Safe status, if it is in use and it is locked, then the locker has been closed after registering.

Emails: we use 2 flow variables to store the email recipient and the flow password as content.
Our emails are created out from a simple email template with some custom styling which has been written in HTML and CSS. We have then converted it into a single line string. In one example we have made it insert password as a string.
This could also have been done in a template node, but we have used the function node.

Much of the logic and inputs in the flow has been created with trigger nodes, which need to be reset before they can be triggered again. This results in most of the complexity in the system with a dedicated MQTT topic for resetting the system when it’s relevant. There are also smaller resets, for example at the unlocking logic for checking if the password is incorrect.

Some places in the flow, there are a few unintuitive delays, for example before a few password/email resets. This is due to ensure that all relevant emails or other flow variable dependent functions trigger before the reset.

Sebastian:

Todays work has consisted of examining, editing and commenting the NodeRed code. Organising the flow with aligning nodes and branches makes reading and understanding easier. Comments can be read to gain better understanding.