The "lock-in" was something initially devised months ago, an idea that involved taking a couple of days towards the end of the semester to commit fully to this module. As the semester began to wind up in terms of general workload, it became increasingly apparent that this "lock-in" would be necessary. In week 10/11 when we finally set it in stone, it was a great relief off all of all shoulders, knowing it was one less module to stress about, especially with already rampant workload due in week 12/13.
With the lock-in pencilled in for the second week of May, it allowed myself and the others to put increased focus on other modules, and helped reduce the stresses we faced at this time. Eventually, the lock-in week did come around, and I and the others arrived in the room on Tuesday 7th May at 10am sharp. We had split into two teams, one team consisting of Emma, Conor and Eric that would look at adding HRV control to a breathing teddy-bear toy, and another consisting of Adam, Hasan, and I who would look to build upon the "wave-machine" idea we brainstormed a few weeks prior. Lastly, Jason and Dominik would be looking at building a wearable, although we ended up just using our own wearable.
As discussed in the previous blog, I had designed a "poster" of sorts that took the chaotic output of our whiteboard brainstorm session and tried to neatly display this information in a way that was a bit more.. readable. We carried on from this idea and created a group Miro board, a kind of virtual whiteboard where we could brainstorm to our heart's content.
Our group Miro board
The Miro board allowed us to collectively collaborate on the direction of the project, come up with ideas for design and implementation, and effectively track progress.
My team, tackling the wave machine implementation outlined a couple of ideas that we would like to implement. We knew we wouldn't be able to touch on all of these in the small, two-day window we had to design the final solution. Some of these ideas included:
Building a wave machine using servo out to control it.
Designing a wearable to communicate via MQTT to this wave machine.
To/from Twitter or Google Sheets using IFTTT.
A calculation of the phase difference for control of the machine.
Artifacts
With eventual goals defined, we got to work on Tuesday morning starting the 3D prints for potential artifacts. Adam had the most experience with 3D printing, and acquired a few publicly available items from a website called Thingsverse to aid us in the project development.
The Wearable
The first artifact printed was a "hospital-style" heart sensor, or rather a housing for our DFRobot Gravity pulse sensor. The idea around this print was to design a quick and simple housing that would allow us to obtain a more consistent pulse from the sensor, as we had encountered problems recording adequate readings during previous use of the sensor.
Printing a wearable to house the pulse sensor.
The 3D printed sensor housing worked quite well, and we quickly found that it fit Hasan's finger perfectly, effectively making him our honorary pulse subject.
Adam showcasing the newly printed pulse sensor, connected to a Micro:bit
We experimented with other potential housings, which I didn't take pictures of. One of them was a bracelet design, in which the DFRobot Gravity sensor sat inside the band of the bracelet and detected a reading from the user's wrist. Problems with this design were the brittle nature of the hardened filament making it difficult to bend, as well as the small size of the band meaning it wouldn't even fit around any of our wrists. The second design featured two detached shells, held together by the elastic strap from the sensor. We found during testing that this design simply wouldn't cut it, as it failed to remain tight and therefore couldn't adequately determine the user's pulse. Ultimately we stuck with the original wearable design, as it offered the greatest pulse detection in the smallest and simplest form factor.
The "Ocean In A Bottle"
Since we had originally seen that first Hughes Wave Motion Machine video, we knew we wanted to try and emulate it. We understood that we would never achieve as pristine a design as Hughes, as according to his website he claims his "products and services are the result of almost 10 years of research, design, and engineering to produce a well-made, visually stunning, yet therapeutic motorized ocean wave display" ref. I felt we wouldn't be able to achieve anything near as stunning as as this design, and that our solution should focus more on the mechanics, and IoT aspect.
A few weeks prior, much to Jason's delight, I had came into class with an "ocean-in-a-bottle", consisting a coloured water/baby oil solution that could be used to somewhat emulate the wave machine design. I had went home after the class prior and created this artifact, to try and see for myself if this idea could bear fruit.
This first ocean-in-a-bottle used a 50/50 combination of water and baby oil. The water was dyed with a couple of drops of food colouring (green in this case, as Tesco had no blue) and added to the empty, clear bottle. The baby oil was then carefully added into the bottle, trying not to "mix" it with the water and create bubbles, and filled to the very brim. The cap was then carefully tightened, trying not to spill any of the mixture. The solution was then left to sit for a couple of minutes to ensure any and all bubbles had disappeared before being slowly put on its side and rocked to simulate the motion of the waves.
My first "ocean-in-a-bottle", created with a smoothie bottle, dyed water and baby oil.
As for the motion of the liquid solution inside the bottle, the class and I were impressed with how the movement looked. Of course, we intended to improve on this design by finding a more suitable housing, and of course using blue food colouring.
Tuesday 7th produced two more iterations of the ocean in a bottle, the second of which made final design.
My second attempt, this time using a narrower bottle and adding a blue colour.
Equipped with a more "ocean-like" colour, the second attempt looked promising. Below is a video of the comparison between the first and second designs, showcasing the "wave-like" motion of the solution inside.
The final "ocean-in-a-bottle" was similar to the previous, but with a different shape. We wanted to toy with the idea of having a more elliptical-base bottle to allow for a greater viewing area - you'll see what I mean in the images below. After a quick escapade to Mr. Price, we found a shower gel bottle that would do the job.
Below is cropped image of that Carex shower gel bottle, while we were in the process of emptying it.
Having a bottle with this more elliptical "()" shape would allow for a larger viewing area when viewing the motion from the side. We didn't fill this bottle up with the baby oil / blue water solution until later in the lock-in.
The Servo Motor
With the "wave" defined, the next step for our wave machine was the.. well, "machine". We knew since the brainstorm that we wanted to look at using a servo motor. A servo motor is a self-contained electrical device that can rotate with great efficiency and precision. The idea was to program the servo to rotate, and then use that rotation to move the bottle, essentially creating waves. The faster or more frequently the bottle moves, the greater the amplitude of the "waves" within it.
The bit we were most unsure about was what way we would translate the servo rotation into linear, vertical movement. The initial idea was to use a sort of "moving bar" that we could tie to the bottle and essentially just lift it up. It's difficult to explain, but below is a diagram I made of what I mean:
Diagram explaining how the servo mount would operate
To attempt to achieve this, Adam went back to Thingsverse to find a servo housing that would suit our needs. He found one that actually allowed for 2 points of rotation, the vertical rotation as shown above, as well as the circular rotation of the actual motor, although we only needed the first.
Adam building the 3D printed servo mount
We then tied a bit of string to the "bar" of the housing, and the other end to the neck of the bottle and tried to lift it. Unfortunately, we found that the amount of distance the bottle would move vertically far below what we hoped.
Testing the vertical movement servo housing on an empty bottle
A redesign was required, and after a while we came up with a new and improved, idea. We ditched the vertical movement for the servo's rotational movement.
Wave Machine Prototype #1
With this new idea, we decided to spend an hour building a rudimentary prototype of our final design, building a housing out of cardboard on which to attach the servo and bottle to. We also experimented with the idea of using a kind of 'offset-pulley' to convert the servo's rotational movement into vertical movement. Below, you can see a diagram I made to explain what I mean. By wrapping the fishing line around this one static point, a smooth movement is created.
Diagram of how a single pulley can change the direction of the force
Below is a demonstration video of this first prototype. We reused a bit of old cardboard and screwed a few bolts into it. The servo was cable tied to the cardboard mounting, and the bottle suspended with fishing line. Upon programming a Micro:Bit to rotate the servo, we had a moving bottle!
Side profile of this first prototype
The Physics of the Pulley System
Immediately we all noticed just how awesome the pulley looked in action, but it wasn't just for looks. A pulley system (consisting of wheels (pulleys) and a rope/string) can be used to create something known as a mechanical advantage, which makes lifting a load easier.
While the initial design used a single pulley to simply change the direction of the force, the video above makes use of two "pulleys". When more than one pulley is used, the weight of the load is distributed across multiple segments of the rope, reducing the amount of force required to lift it. The mechanical advantage is defined by the number of rope segments supporting the load.
Below is a video of this prototype functioning with the bottle filled with solution!
That concluded our progress for day 1 of the lock-in, and I was looking forward jumping straight back in the following morning and improving our design.
Wave Machine #2
The two main goals for day two were to improve on the physical design of the prototype, and of course get the system working with MQTT and HRV.
Let's talk about the wave machine redesign first. Obviously the cardboard base needed to be replaced with something a bit more.. presentable. With sustainability in mind, we find two old folders that were set to be thrown out and combined them together, using one as a base, and another as a vertical mount.
These folders were sturdier than the cardboard we'd used yesterday and also looked quite nice as a backdrop.
As well as this, yesterday we had been using bolts as our pulleys, which didn't make a huge amount of sense in my eyes. A 'pulley' is made of two things: a string, and wheels. I brought up the idea of replacing our bolts with wheels, allowing them to spin, providing a better system and cooler appearance. The lads loved this and Adam found some pulley schematics to 3D print on Thingsverse.
For the second machine, we added a third pulley, giving the system a mechanical advantage of 3, meaning the bottle would require only a third of the force to lift. After about an hour or two, we had it built, and it was glorious.
The second physical solution, in all its glory.
An in-depth look at the pulleys
This second 'prototype' worked almost exactly the same as the first, just in a much cooler and more appealing fashion.
With the physical side completed, the next step was getting it reading our HRV and sending it to the machine through MQTT. To do that, we needed to write some code.
The Codebase
I would say I took the lead for the code side, particularly when it came to the servo control. For the other parts like the cloud board and wearable code, both teams made incremental improvements to the same code, as those parts were dual purpose.
The Wearable
We spent much of the lock in using the same wearable code we'd looked at back many iterations ago, when we used a kind of 'autocalibration' to achieve a more accurate heart rate sensor reading. This wasn't really giving us the result we wanted in the final solution. Thankfully, Jason told us how he had spent some time trying to improve this code, and sent us his most up to date version, which can be found at the link below. I wont go into great detail about most of the code here, as I've done that in a previous vlog.
On the right side of this code screenshot, you can see a large 'else-if' map. I did this myself, taking a range of HRV values and converting them to servo motor angles.
Mapping HRV values to Servo motor angles
The MQTT Design Pattern
To be honest, the MQTT design pattern hasn't changed from our previous testing. This is purposeful, as it's important to have a fundamental design pattern that you know works.
This pattern allows us to send and receive our HRV values from the cloud using the Beebotte MQTT broker, a MicroIoT Cloud Board v1, two Micro:bits (wearable and servo) and an MQTT Client mobile application.
Below is a screenshot of the live data on the MQTT client application.
A screenshot from the MQTT client application, showing the live HRV values.
A Brief Glimpse at IFTTT
As briefly mentioned earlier, I looked at trying to integrate IFTTT (If This, Then That) into the final solution. My idea was to use an IFTTT Applet to add lines to a Google Sheets spreadsheet, recording the user's HRV data at the same time as it's controlling the wave machine.
Unfortunately, we ran out of time for the lock-in before I managed to fully integrate it, however I did manage to get some basic values added to a spreadsheet whenever I interacted with the Micro:bit.
As you can see from the image below, it took a few attempts before I got the hang of what the different values needed to be in the IFTTT app.
My IFTTT spreadsheet
To get this work, a piece of code was added to the cloud board code to send an IFTTT webhook.
Below is a video demonstrating this rudimentary use of IFTTT in action.
The Final Solution
I thought the final solution was pretty awesome, although it did encounter problems. We had real issues 'translating' the already inaccurate heart rate readings, and converting it to servo motion. Although we all believe we could have improved it much further, by 5pm on lock-in day two I was happy with what we had done.
Below is a video demonstration of the final solution in all its glory.
Conclusion
For me, the world of Internet of Things was completely new. I had been studying as part of the Applied Cloud and Networks stream, and had never been exposed to almost everything we looked at throughout this module.
I really enjoyed the hands-on learning we did, the group work, the brainstorming, the presenting and more. My favourite aspect was definitely the teamwork, and I felt the learning style helped us collaborate far more that we'd ever had the chance to in previous modules. Learning about MQTT was a highlight for myself, a powerful messaging protocol I hadn't come across previously. IFTTT was incredibly interesting, and I felt the whole concept of HRV as a primary focus point provided a really good foundation for the module as a whole.
I'd like to thank Jason for all he did for us throughout the module, and my classmates Hasan, Adam, Emma, Conor, Eric and Dominik. They all helped make this module a really enjoyable experience and a welcome break from the rest of the busy college schedule.
What Did I do for the Lock-in?
I got really involved for the lock-in, instrumental in the design, build and coding processes.
I designed two different ocean-in-a-bottle prototypes, and filled all bottles with the oil/water solution.
I and the other two lads built the original cardboard mock-up, with I proposing the idea of the triangular prism stand. I also remembered that there were old cardboard folders in the stairwell outside, and proposed using them for the second iteration.
Changing the pulleys to be 3D printed wheels rather than bolts was an idea of mine.
I spear-headed my team's code design, staying a little later on day one to get the prototype moving with heart rate!
I also created and hosted the final Beebotte MQTT topic that we used for messages.
Drew the short straw, being the unfortunate one who had to buy a litre of baby oil from Tesco 😆.
There is likely more than I'm forgetting to talk about. I saw this as a collaborative team project, and as such I feel that most of the work was done equally. There are many aspects in which it would be unfair to say "I did this", when it was in fact a group effort.
What did my team do for the Lock-in?
I think I described in pretty good detail in this blog exactly what my team as a whole did. There are certainly bits I missed that I'm sure the others picked up on. Overall, I'm proud of the work Hasan, Adam and I did in creating this wave machine in just a handful of hours over two days. We took a concept to a finished, physical solution, that actually worked!
Iteration #2 - Micro: Bit Research & HRV Jack Duggan | 20094010 | IOT Apps For the second iteration sprint of the module, I got hands-on with the Micro:bit. I had previously used these devices way back in secondary school for Leaving Certificate Computer Science, so the basics came back to me fairly quickly. We were sent home to 'research' the Micro:bit, and become familiar with it's basic functionality, before class on Friday the 2nd of February. In the class, I worked alone (as we had an odd number of students present) with a Micro:bit V2, an expansion board for the Microbit, and a heart rate sensor. Above is the physical setup Below is the device output screen with my finger on the sensor. The top graph shows my pulse as analogue input as identified by the sensor. Some mathematics is performed (as shown under the below graph) that converts these pulse values to HRV (delta_t). This HRV value is then displayed on the 'boxier looking' graph underneath. The way t...
What is it? Heart rate variability (HRV) is the measure of the variation between heartbeats. It is controlled by your autonomic nervous system (ANS). This system operates automatically and regulate process such as the heart rate and other bodily functions that are are not under conscious control. This system is broken into two branches the flight or fight (which preparing the body for action and stress) and the rest + digest (which promotes relaxation + recovery). HRV is influenced by the ability to smoothly shift between these two branches. High HRV: Larger difference between successive heartbeats - Indicates a more flexible and adaptable autonomic nervous system. Low HRV: Smaller differences between successive heartbeats - Indicates a less flexible autonomic nervous system. ...
.png)
Comments
Post a Comment