Today we worked on moving all the code to only one NodeMCU. Last night we realize that if we use the TX and RX pins and use the same tricker pin for all the ultrasonic sensor, we could fit everything on one NodeMCU. This meant changing the code all over again, but it solved a lot of the problems we where in encounter, with the two NodeMCU. This took a good chunk of the day to finish off.
When we wanted to test with NodeRed, we found at few mistakes, ui-controller not changing dashboard as they should, we found the mistake in the coding, change it, and everything was working again.
We startede filming the video, the clips whit out the machine were very easy to shoot, and the edit of the first clips went super fast, but we had a bit of trouble with the machine, and just when we were about to be done, we fried the NodeMCU that we were using. So we change over to another NodeMCU, but starting having trouble with the OLED, to the prototype apart again and then we found out that it was a broken cable. Now the everything was running, and we check the math from the code, and made a few adjustments to make it work better.
The rest of the group who was not working on the coding, worked on the report, the PRD, and the BOM. We also spent this reading though the prototyping planers. Around midtnight all this was done, we started filming clips og the NodeRed dashboard.
This is how the final prototype turned out, a last we got every thing to work, but I took a long time, and we finished of in the morning, and tired, but happy that know we are done with the prototype and now we only need to present it.
We made a rendering of how we wanted the finish product to look. The frame should out of white plastic, and the cambers should be transparent.
At the beginning of the 3 week period, we made our own deadline to finish the product today. The thought behind this was, that if we finished the product by day 10, we would have 4 days to make the video, the report, finish the BOM and the PRD. Today we got at big step closer to finishing the product, but it is not build yet.
Connectivty
One of the reasons, we did not finish the product today, was that we wanted to run all of components from an Arduino Mega and store the code on this. To get the Arduino Mega connected to MQTT, we wanted to establish serial communication between the Arduino and the NodeMCU, we spend a lot of time on this, but we could not get it to work. Then we tried using the NodeMCU as a WIFI-Shield, for the Arduino, but this would not work either. Our back-up solution was to have multiple NodeMCUs and run all the code from here, but this added a few new problems, like the fact that one motor has to run, then the pump and then the other motor, because of our power supply.
The Frame
The process of building the frame
We had already made a drawing of the frame, but today we realised that the frame we made, is not strong enough to carry the load of everything, so we needed to find a new design to be sure that it would not break. The GIF above shows the process of designing the new frame. The end result is where we are today. Tomorrow we need to make a few different changes to make the frame stronger and more balanced.
The frame now
Kickstarter movie
To get inspiration for the movie, we looked at different movies on kickstarter, and movies made in this course previous year. To show off our product we decided to start out the video with a clip of a sourdough user coming home from vacation to a moldy sourdough, after these the “CEO” will start talking, the shot will change between the “CEO” and shots of the product. After this the “developer” vil start talking about the product, and shots of the assembling process and coding will be shown.
The “CEO” is going to be played by Ruben, the user is played by Emilie and the developer is going to be played by Aksel. Daniel knows most about filming, therefore he will be in charge of the filming.
One of the things we believe to be most challenging about the mechanics of the sourdough machine, is dispensing the flour. Flour is generally hard to pour evenly, for example when pouring it from the bag to a bowl. It tends to stick together when tilting the bag, before it suddenly slips and too much flour falls into the bowl. Therefore, we needed to make a prototype to test if it would be beneficial to dispense the flour by moving it with an auger screw which we 3D printed. We tried moving it upwards, sideway and downwards and learned that moving it upwards is possible, but very hard. Therefore we figured that this would not be the most efficient way to transport the flour. Moving it sideways, however, is possible and works quite well.
Testing the auger screw sideways
The auger screw is inside the pipe
The problem with moving it sideways and downwards was that not all the flour would fall down and get fed into the auger screw. Most of the time the flour would build up along the side. We also tested different types of containers.
We also drew drafts to decide the size and placement of the components, to make sure that everything will work together. The plan for monday is to start looking more at the shape and sizes of the containers and testing the water pump.
First prototype of the mixing chamber and the mixing blade
For our final project we have chosen to make a sourdough machine. The target user is the home baking enthusiasts – the person who like to make great bread using their own sourdough.
We discovered the need for a sourdough machine, as we, and people we know have struggled to keep their sourdough alive, especially during busy periods or when going travelling. You can put your sour dough in the fridge, but only for a short period of time. After a week you risk that your sourdough goes bad.
The Sourdough machine will keep the sourdough alive, by mixing the dough, with certain interval, based on the room temperature. Every day or every other day the dough will be fed, which means adding flour and water. After the feeding the machine will mix the dough with flour and water till the mixture is homogeneous.
The user can choose between 3 modes: “Start a new Sourdough”, “Travel mode” and “Keep it Kicking”. The modes are controlled from the webapp.
The Start a new Sourdough setting will mix water and flour to start a sourdough from scratch. When the starter is finished the user turns on “Keeping it Kicking” which is the default setting. On this setting the sourdough is kept alive and the user can put in the dates where he or she is going to bake, so that the machine can make extra sourdough. When the sourdough is not used for baking, the user has to remove some of it every other week or whenever the container is full. If this happens, the user will get a notification. The user will also get a notification if the machine is out of water or flour, no matter the setting.
The Travel mode is for keeping the sourdough alive, when the user is away from home. When starting Travel mode the user will be asked, how many days the Travel mode should be active. They will also be guided through how much sourdough to remove, to make room for the growing dough. On travel mode less water and flour is added every day to keep the dough active and also make sure that the dough can fit in the container and that the machine does not run out of flour and water.
Components
3x stepper motor
3x stepper drivers
3x ultrasonic sensor
1.3 inch OLED screen
1x peristaltic pump
1x RTC
BMP module
NodeMCU
Arduino Uno
(Peltier elements)
(Weight)
Time schedule
To get a overview of the project we made a timeplan. We decided to aim for being finished with the machine on the 20th of June, to make sure we have time left to finish the report and make the video. We plan to finish everything on the 25th of June, so we will have time on the 26th of June, to make the final preparations for the exam.
Before the Easter holidays, we wanted to try and finish the project, in order to enjoy our vacation time. Therefore we worked hard during the time in class, and we met up to spend a whole day together working on the project.
During the class we worked with the NodeRed, the NodeMCU code and with incorporating the buzzer. We also made our first locker prototype out of cardboard.
When we meet up on the following sunday, we startede with making a to do list, and then dividing the tasks among us.
The user flow draft
We also drew up the user flow in order to get an overview of it. In short the user would come, sign up for the locker, put in their stuff, close it and walk away. When they go to pick their stuff up again and close the door, the locker should reset. But to make a successful locker, there are different cases that we need to account for.
The first scenario is that the user signs up, but then changes their mind, and doesn’t close the locker. We agreed that if the locker was left open, it should reset after 5 minutes, and that the OLED should write “Close me”.
The next scenario is that the use does not come and pick up their stuff. Should the locker reset after 24 hours? 48 hours? or 72 hours? We agreed that it should open and reset after 48 hours, and that we wanted to send an email notification to warn the user 2 hours before the locker would open automatically.
The user flow
The code
After making the user flow diagram, it got clearer what the NodeMCU should communicate to NodeRed and vise versa. We decided that, based on the function, there should be different topics, so the communication between NodeMCU and NodeRed would become more readable. It also made it easier for us, to implement a function that directly takes the payload from the NodeMCU to the OLED, without printing things unnecessarily for the user. Our whole setup has been made to ease the memory of the NodeMCU and do as much functioning possible inside NodeRED. In one line; the nodeMCU controls the hardware and NodeRed handles the UI and UX.
The code has also been cleaned up, so that only functions, we still use, remain. The text for the OLED was changed, so that it matches the lockers status. It will say “The safe is available” when not in use, “Welcome to the locker” when the user is putting their belongings in, “The safe is in use” when in use, and “Please close me” if it has been open for more than 5 minutes. The different buzzer sounds were also successfully implemented (see separate blog post).
NodeRed
We also continued reorganising the NodeRed. We set up the log-in forms, so the user could fill in their email and password when signing up, and insert their password for unlocking. We wanted the user to receive an email with their chosen password
We had a bit of trouble, with NodeRed remembering the users password and matching it to the e-mail when signing in. No matter what it would just say wrong password. We made the password a flow variable and made a switch (a NodeRed node, a glorified if elif, else statement), where it checks the sign in password against the sign up password.
The emails we created with NodeRed, was a bit simple and they looked very plain. Therefore we made the different emails we needed with HTML and CSS, to give it a nicer, more readable design. There is an email for the sign up, the 2 hours warning email, the reset email after 48 hours, an email for wrong password, an email for correct password, and one for the 5 minutes reset. This could be improved in the future by using NodeRed template nodes.
The locker
The first prototype of the locker was a simple box, with a hole for the OLED and space for at shelf to hide the Node MCU and the breadboard. Both the prototype and the final locker would be laser cut.
The cardbord version
During the class we cut the first version of the box, in cardbord, but later we decided to change the design a bit.
The cardboard version
We changed the corners to rounded corners, and we added a hole for the buzzer. Read more about the changes in the blog post about the locker assembly.
The set up the lock, we had to set up the different cloud services.
First of all we need an account for IBM cloud, Sebatian and Aksel made two different account. The IBM cloud gives acces to NodeRed. We also made at an MQTT server.
From the NodeRed, we can via the MQTT send different messages to the NodeMCU, and we can also send message from the NodeMCU to the NodeRed – also via the MQTT.
To begin with, we controlled the lock in a simple way. In the NodeRed we set up a flow, connected to the NodeMCU, and programmed the lock to open if it received the text “unlock”. The unlock message is send from a text field. Other messages typed in the text field could also be send and showed on the OLED.
Afterwards we created an unlock button in the NodeRed instead, which sends the unlock message to the MQTT, so that the lock would unlock and the OLED would show “unlock”. All messages was send from NodeRed via the MQTT server to the NodeMCU.
Today we started project nr. 2. in the course Mechatronics Engineering Design.
To start our work as a group we discussed our ambitions and what we want to learn during the project. Then we started planning the project, which functions we want to have, what materials, and what components we wanted to include.
Until the next time, everyone will make a few design drafts and a look into the IBM cloud services.
Chindogu 