Iterartion 5 - Lock In - Eric Butler
HRV Iteration 5 - Lock In
As agreed a few weeks prior, we decided to have a 'Lock-In' on the 6th and 7th of May to ensure we could have two full days to finish out our project and develop the concepts discussed in the brainstorming. This two-day period would operate from 10:00am - 4:00/5:00pm depending on where we were with the project on that given day. I will split the work up between the two days, describe what happened each day, and give some details of the difficulties faced and some learning outcomes.
Brainstorm Revisited
Below I will leave a picture of the brainstorm, similar to the last report for ease of reference. The general concept is the same but Jack took the time to draw it up in Canva to make it more visually appealing.
.png)
Brainstorm re-done on Canva
Aim
Our aim as mentioned in the brainstorming was to have two separate teams create two different projects, The two projects we decided on was the Teddy Bear concept where we have the Teddy breathe to the HRV ( Depending on the rate would increase or decrease the speed of the bear breathing, and the Wave Machine concept where we have a container filled with a liquid with less density to capture the wave effect. For this, we would use baby oil and colour it blue. Similar to the design shown below.
This is the sort of idea we were thinking about with the wave machine but alternatively, we would make our own. The idea was that you have it connected to a heart monitor that would tack your HRV and depending on the value, it would change to be higher and bigger crashes or lower and calmer crashes. This would be done by sending the radio signal values to an MQTT server which in turn connects to the Micro-bit and operates a motor to change the speed of the machine.
Talking a bit more about the Teddy Bear, we decided to go with a Breathing Otter that we would be able to wire a microbit to and control the motor within it through the microbit. This motor operates a breathing feature in the bear and so would be the best for what we wanted to do which was to have it breathe to the HRV of the user. This particular bear was suggested by Emma and agreed upon by Jason (The lecturer), Conor and Myself. A picture of the bear can be see below and later I will discuss and show the functionality of some of the features.
Team Distribution
We decided upon the teams for the two different projects. For the Wave Machine, it was decided that Adam, Jack, Hasan, and Domonik would work and develop this project. For the Teddy Bear it was decided that Conor, Emma and Myself would work and develop this project and so for the rest of this blog I will be referring to the Teddy Bear and how we got this to be a functioning project.
Day 1
Day 1 started out with us reviewing the brainstorm in order to find out what our tasks would be as well as looking and all the code we had and seeing what we could possibly use for the project to save time. As well as this I opened up the motor on the Teddy to see how the microbit had been saldered. This was done by Jason which I thought was safer due to us not having much soldering experience, coming from a different stream. To investigate this, it required to unscrew the casing to where the motor and circuit board were in order to follow the wires to see which wires connected to the Microbit, Speaker, Motor, etc. As well as this I tried to find the LED which the product was advertised with but to my surprise, I couldn't find this. I had Conor and Emma look too, to no success. It was then decided that we would just continue with the breathing feature and install an LED later.
While I was taking a look at the bear, Emma was also investigating this with me while Conor continued to look through the code and find out how we could get an idea of the motor running. All the while Adam had the 3D printer going and was making thumb pieces for the sensors that would make the contact patch of the infrared LED and our finger more consistent.
Below is the video of the motor working when the button on the micro bit is pressed
I will show a newer version of the code to below as the version this started with was overwritten and it will make more sense to explain it in 'Day 2'. To give a brief rundown of the code it is similar to code we were using in previous iterations in order to test functions such as LEDs to activate based on button presses.
To close out 'Day 1', we were left with some questions regarding what we needed to proceed with. After setting out the ground work, Emma and I looked into the bear and how it worked, helped Conor with some debugging, and got the motor running to the button press. We were still left with some questions, where the psudo code related to the Teddy was (Some minor code Adam had stored on his PC), and some other questions regarding how we would achieve connecting to the MQTT server without an Android phone, we documented these questions and called it for the first day.
3D printed clamp by adam
Day 2
Day 2 is where the project fell into place. We had gotten the code we needed and had started to work on Cloud to the MQTT App as well as the Breathing Technique code.
Teddy Code
Emma and I began work on getting the breathing sequence down with the bear through the motor. We had to come up with a way of using what we learned throughout the last iterations to develop a breathing pattern based on the value being received from the MQTT server and depending on this value it will trigger the intensity of the breathing.
We ended up having to install an extension that will allow us to have the motor functions so we can simplify our functions by using the set Motor to 1 (On) or 0 (Off). This allows us to create functions that work on 'If-Then-Else' e.g. If the motor is motor is on, set the direction to forward, else if it's off don't do anything. This means we can set 'On-Button-Pressed' to turn on the motor and receive the radio signal value. This technique was used to build a pacer when the B button is pressed. More details below.
As well as this Emma had suggested a way of changing the speed based on the HRV and that was to add the different 'if' statements you see on the screenshot below. This method essentially creates ranges based on the HRV to speed up or slow down the breathing. Below is the screenshot of the code block.
Teddy Code
MQTT / HRV Monitor Code
The server code is something Conor had started to work on and used a lot of the code we already had and used in previous iterations to send values from one microbit to the MQTT server and then to another person's microbit. Conor had to make minor adjustments to this (mainly adding the MQTT server code and the code Jason had shown us while monitoring the HRV). Below is a screenshot of the code.
HRV to MQTT server code
Pacer Details
The details on the pacer were to use a 4-4 technique also known as 'Square Breathing'. This technique implies an inhale for 4 seconds, hold for 4 seconds, and exhaling for 4 seconds and works as a way to calm yourself down in intense situations or to have overall better breathing. As mentioned in my last report, this is a technique used many many professional athletes, and military personnel, as well as a meditation tool. Below is a diagram that will show the idea of how to do this and for explanation into why we picked this type of breathing.
Project Demo
At the end of 'Day 2' it was time to show Jason what our project had become and what we had managed to achieve. This was done by setting everything up and running Jason through what the Teddy Bear does, in relation to the microbit being pressed both the HRV Reading and the Pacer functionality; as well as running him through why everything is happening i.e. The Sensor reading our HRV, sending it to the MQTT server, then the MQTT server sending that Radio Signal Value to the Teddy microbit and operating appropriately.
Once Jason was satisfied with what we had demoed, He suggested that we take videos and photos of everything working. Here I will include some of those videos of the demo as well as some photos of the apparatus.
MQTT Server App
In the screenshot above is the MQTT server app, we had to configure a new connection type for the cloud board in order to be able to send and recieve radio inputs too and from the Teddy. This was done in a similar way to our last iterations but did come with it's difficulties as I will explain in the 'difficulties section'.
Cloudboard hosting the MQTT server. Getting internet connection from Android hospot in order to run.
Difficulties
One of the main difficulties faced was the inclusion of IFTTT. Coming to the end of Day 2 it was the last thing we needed to do in order for our entire project to be sucessful and to fully show our knowledge of IoT apps. Going from similar iterations of using IFTTT to send emails from the Microbit, we set out to see if we could play a spotify song should the HRV become to low. To do this we would create a function in our teddy code that would activate based on one of the ranges in the 'if' statements of ranges.
Upon Conor creating a webhook on his phone, we tried to configure the server code with an API key and an event trigger, to trigger the function based on the HRV. After debugging for an hour or two, double checking of our configuration and all was correct we couldn't find an answer. Our main concern being the fact we were sharing 1 Version 1 cloudboard with the other group due to lack of availablity. This meant that we all had to be on the same radio network and so, it was hard to differencate what we wanted to send and what the other group wanted to send on their side for their project.
Should we have had our own cloudboard, it is fair to say this solution should have worked in theory and so we didn't progress further on the IFTTT side. We did however notice that the values the we needed to send to the server were coming through, although it was not coming to Beebotte which is the hosting protocols we decided to use. Below is a screenshot of a close up of the configuration code for Beebotte.
Conclusion
To conclude the Lock-In and IoT Apps, it's fair to say that we achieved our main goal of creating an "IoT App" and so anything else would have been a bonus. Throughout this module I learned alot about not only IoT software and delving more into cloud and networks but as well as about teamwork, communication and excution. I learned how to take concepts and use my thought skills I've learned throughout my degree to execute a detailed brainstorm with good commmunication to all members of the team.
I also learned that even failure is good for learning, how to tell someone about a problem instead of just not knowing, how to come back from a bad day of work and move forward the next day and achive my goal and most importantly bring passion and enjoyment to what I was doing. For someone who has never touched IoT to be able to communicate the process of it to a lecturer after just 12 weeks was definetly a good learning outcome as well as something I enjoyed alot. Having the desire to come into Jason's class, in the welcoming environment he creates definetly made me engage with the module more then I think I would have if I was just told to go off learn X,Y,Z and come back.
I want to finish by saying Thank You to Jason for being again making the module really enjoyable and different to anything I had learned, and to my classmates who I teamed together with the develop a concept in a enjoyable and productive way. I've definetly learned a lot not only technically but also professionally and personally by doing this module that I can no doubt use as I begin the next chapter of my career.
Comments
Post a Comment