Before diving into the actual lock project, we began by distributing the workload to clearly define who would be responsible for each aspect of the project. Given our objective to implement two distinct ideas using Heart Rate Variability (HRV), we devised a plan that included both a teddy bear and a wave machine, each designed to simulate HRV in unique ways.
The first idea involved creating a teddy bear that could mimic HRV. This project aimed to provide a comforting and interactive experience, particularly for children and mother, by having the teddy bear's movements or vibrations align with a person’s heart rate variability. This approach required careful consideration of the mechanisms and sensors needed to accurately capture and reflect HRV in a tangible and soothing manner. Luckily we found a teddy bear that have display some of the mechanics that we reguired such as motor that simulate breathing - Fisher-Price Soothe 'n' Snuggle Otter | Smyths Toys Ireland
The second idea focused on developing a wave machine that also simulated HRV. This device would visualize the fluctuations in heart rate, offering a more abstract but visually engaging representation of HRV. The wave machine project required a different set of skills and considerations, including the design of the machine, the programming of its movements, and the integration of HRV data to drive the visual display.
By dividing these tasks among team members, we ensured that each project could be developed concurrently and efficiently. Each team member's interests were matched to the specific project - we were allowed to request to be on a specific team.
As seen in the above image, we used a Miro board to facilitate this selection process and to remind everyone of their team assignments and project responsibilities. The Miro board served as a visual and collaborative tool, allowing us to clearly outline who was responsible for each aspect of the project and to track the progress of both the teddy bear and wave machine HRV simulations.
As seen on the Miro board, I specifically requested to be on the teddy bear team. My interest in this project stems from my desire to create a comforting and interactive experience, particularly for children. I am passionate about developing tools that can provide emotional support and well-being, and I believe that the teddy bear HRV simulator has the potential to make a meaningful impact. As I myself am currently trying to overcome my own social anxiety. Additionally, I have a keen interest in the mechanical and sensory integration aspects of this project. My fellow team members were Eric and Conor.
Brain Storming Teddy bear Team
The very first day of the lock in we decided to firstly brain storm further ideas for the teddy bear and to weed out ideas that perhaps are too much trouble. On the very first day of the lock-in, we began by brainstorming additional ideas for the teddy bear project and identifying concepts that might be too problematic to implement. This initial session was crucial for refining our approach and ensuring that we focused on feasible and impactful features for the HRV simulation teddy bear.
Eric was the main driving force behind this brainstorming session. Although I was the one who initially found the teddy bear, it was Eric who enabled us to incorporate it into our project. He presented the idea to the lecturer and suggested opening up the back of the bear to explore potential modifications. His initiative and creativity were pivotal in advancing the teddy bear HRV simulation concept.
Some of the ideas we had involved incorporating the teddy bear's built-in features into our project. These included utilizing the music and built-in speaker, integrating the LED light, using the motor to simulate breathing in and out, and repurposing the button on its front.
Built-in Speaker: Our plan was to use the built-in speaker to respond to the HRV data received from the MQTT. If the HRV indicated poor condition, we aimed to play audio that would guide the user through paced breathing exercises or soothing music to help improve their HRV. (We had aimed to this through IFFT up form the otter to our phone that would play spotify) This feature would provide real-time, auditory feedback to support the user's emotional and physiological well-being.
Music: If the idea of using custom audio proved too challenging, we had a backup plan to utilize the teddy bear's original built-in audio. This audio would also play in response to the HRV data, providing an alternative method to support the user based on their HRV readings.
LED: Our plan was to activate the LED light whenever live data was received from the MQTT server. This visual cue would provide real-time feedback, reassuring the user that the teddy bear was actively presenting HRV data. It would alleviate any concerns about potential interruptions or technical issues, ensuring a seamless and reliable user experience. Additionally, it would help ease worries if the HRV suddenly appeared alarmingly bad, as it could be attributed to technical issues rather than actual physiological concerns.
Motor: Our concept involved controlling the motor's speed based on the data received from the MQTT server. This dynamic adjustment would allow the teddy bear's simulated heartbeat to speed up or slow down in response to real-time HRV data. By mimicking these physiological changes, the teddy bear would provide a visible representation of the user's current state, enhancing the overall interactive experience.
After planning out our ideas, the next step was to figure out how to utilize the motor effectively. Since it would serve as the main visualization tool for users to observe their HRV, we dedicated time to exploring its functionality and integration within the teddy bear. This involved considering how the motor's movements could accurately reflect the fluctuations in HRV data, ensuring that users could easily interpret and engage with the visual representation of their heart rate variability. Me and Conor were the main ones to play around with this functionality.
The code continuously checks the value of the OffOn variable.If OffOn is 1, Motor1 is turned on and runs at the speed defined by the speed variable. If OffOn is 0, Motor1 is turned off. This setup allows for simple control of a motor, turning it on or off based on the state of OffOn. - During testing we set the variable to random numbers such as 20, 50 and 100 to see the effect it had on the motor. The on/off variable was set by pressing the button b button and turn off by pressing a + b.
https://youtu.be/Q-70j5eJP38
That day, Conor and I also began developing the pacer function for the teddy bear, which guides users to breathe in for four seconds and out for four seconds. Additionally, I implemented a feature to prevent the motor from stopping abruptly when pressing buttons A and B simultaneously. However, this feature became redundant when we integrated the code to handle live HRV data, as we needed to use the buttons to switch between the pacer mode and live HRV data mode. - Basically if i left in my code it would effect the main code for the live HRV data.
The other team was simultaneously working on a user wearable device that both teams could utilize to measure HRV. Ultimately, we all agreed to use this wearable for our project. I believe Adam was the main driving force behind the development of this device.
This wearable ensured that the correct amount of pressure was applied to the sensor, allowing us to obtain the most accurate HRV readings possible. These readings would then be sent to our teddy bear via the MQTT server, ensuring seamless integration and real-time data transmission.
Essentially, the architecture we are using is based on the following workflow:
HRV Measurement: The micro:bit, using the wearable device, measures the HRV.
Data Transmission to Cloud Board: The measured HRV data is sent to a cloud board.
MQTT Broker: The cloud board then sends the data to an MQTT broker.
Client App: The MQTT broker forwards the data to our client app.
Teddy Bear Micro:bit: The micro:bit with the teddy bear code listens for HRV data on radio group nine, receiving it from the cloud board.
This setup ensures that the HRV data flows smoothly from the wearable sensor to the teddy bear, allowing for real-time HRV visualization and interaction.
We have successfully implemented this architecture in previous iterations of our project. This experience has provided us with a solid foundation and confidence in our ability to accurately measure, transmit, and utilize HRV data for real-time interaction with the teddy bear. We achieved all this on the first day of the lock in.
Second Day Lock In
On the second day of lock in we focused on the actually functionality of our project began working on the code.
input.onButtonPressed(Button.A, function () {
OffOn = 1
basic.showString("hrv")
})
Sets OffOn to 1.
Displays the string "hrv" on the micro:bit's LED screen.
Indicates that the device is now in HRV mode. (Meaning the speed of the motor will be based off the reading from the HRV)
input.onButtonPressed(Button.AB, function () {
OffOn = 0
})
When button b + a is pressed:
Sets OffOn to 0.
Stops the motor (as seen in the motor control code).
input.onButtonPressed(Button.B, function () {
OffOn = 3
basic.showString("pacer")
radio.sendValue("spotify", 0)
})
When button B is pressed:
Sets OffOn to 3.
Displays the string "pacer" on the micro:bit's LED screen.
Sends a radio message with the name "spotify" and value 0.
Indicates that the device is now in pacer mode.
radio.onReceivedValue(function (name, value) {
if (OffOn == 1) {
if (name == "i1") {
if (value >= 651) {
led.toggle(1, 4)
speed = 50
} else if (value <= 646) {
led.toggle(2, 4)
speed = 100
} else if (value >= 800) {
led.toggle(3, 4)
speed = 20
}
}
if (name == "fan") {
pins.servoWritePin(AnalogPin.P16, value)
basic.pause(2000)
}
}
})
When a radio message is received, the handler checks if OffOn is 1 (HRV mode).
If the message's name is "i1" ( iI is the HRV data that it recieves):
Toggles specific LEDs based on the value.
Adjusts the speed variable accordingly.
If the message's name is "fan", it writes the value to a servo connected to pin P16 and pauses for 2 seconds.
This is all the variables we used:
let UpDown = 0 - it was to make sure that the motor dose not stop in the middle
let speed = 0 - speed of the motor
let OffOn = 0 - One or off to decide if it should be on HRV mode or Pacer mode.
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...
Iteration 5.2 | The Lock-In 🔒 Jack Duggan | 20094010 | 10/05/2024 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 H...
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. ...
Comments
Post a Comment