Sydney’s Status Report for April 29

This week I mainly worked on figuring out how to turn our rudimentary visualization into something much cleaner looking using THREE.js. So far , I have not had much luck, as this is an area I have little to no experience in. I was eventually able to find a good example that I think I will model my code after. https://threejs.org/docs/scenes/bones-browser.html

The idea being that I will represent the spine as a cylinder, then have each quaternion apply a rotation to some points on that cylinder, such that we can see the bend / movement of the spine.

I also started to assist Rachel with the bluetooth this week. Unfortunately, I was not able to accomplish much due to other final projects being due, but I am hopeful that next week I will be able to realize my visualization goal. I am a bit behind schedule, as I was hoping to have the visualization done today, but I am confident that as my schedule clears up, I will definitely be able to get it done by early next week.

Sydney’s Status Report for April 22

This week I finished implementing and testing the bluetooth. We made sure that it read the correct data, and started/stopped reading data at the correct times(when the user starts / stops  a set). I also worked on our final presentation slides. I also tested to make sure that our device works with the battery(it does, yay!) and it  can run for at least an hour, which meets our battery life requirements. I also finally got the visualization partially working on the website, as Jasmine was able to help me with transfering the data between pages. A picture of a visualization of the orientation of a single sensor is shown below. My next steps will be to create a visualization that represents the entire spine well. Via testing Iw as able to confirm that the visualization displayed matches the physical orientation of the sensor.

I would consider myself on track to be done by the final demo. This coming week I am going to continue refining the visualization and testing to make sure that it matches our expectations.

 

Sydney’s Status Report for April 8

This week I worked on adding quaternion animation to the website. This worked successfully and now we can see the quaternions over different points in time visualized. This is still on a fake data set however.

 

Next, after the new arduino board arrived on Friday I got to work on the bluetooth with the on board quaternion processing and was able to begin transmitting one characteristic of data to the web service. I would call this a very succesful week for me, and am on track. Next week I am going to work to have the data stream to the quaternion visualizer be our raw data, as well as adding a trigger on the website to tell the device to start recording and sending the quaternion data.

 

To ensure my portion of the project meets our specification I intend to create the visualizations of the quaternions and visually confirm that the sensor readings match the relative position of the back. I might user test this on multiple different people to ensure it matches across multiple user profiles.

Sydney’s Status Report for April 1

This week I mainly worked on optimizing our libraries so we could both use the onboard DMP processing to get quaternions as well as the arduino BLE library. This was a real problem as our program as previously written was using 120% of the program memory space. Unfortunately due to problems around that we have yet to fully test the bluetooth integration(but this will hopefully happen tomorrow before the interim demo). But after spending a couple hours better understanding the libraries and removing functionality unused by our application I was able to get our program memory usage down to 99%. This progress is visible on our github. I also worked with Rachel a bit to decide on how to sew the devices together and make sure it matches our vision. We are just barely behind as we were hoping to have the data read to the web server by now, but I think after tomorrow that will be done, and then next week I will dive into working on the foot sensors and assisting Jasmine as needed on getting the detection algorithms working.

Sydney’s Status Report for March 25

This week I primarily worked on getting the IMUs working with the mux. I ran into a lot of problems with the IMU’s not being detectable once connected to the MUX, but after troubleshooting for several hours, realized that for whatever reason with the MUX, I was only able to read the sensor data if I decreased the clock speed for I2C to 100kHz. So I am officially ‘done’ with getting the back device working / reading data. My main goal for the upcoming week is going to be getting the bluetooth from the arduino to our webapp working so that the users’ data can actually be displayed / processed. Luckily, I am actually mostly caught up now. I still haven’t made any progress on the foot device, but after working with Jasmine to get bluetooth working I will get started on that. We were also able to get a bluetooth example working, so I am hopeful that converting the example to our application specific use case won’t take significant time.  Unfortunately because of the issues with the MUX, our placing sensors onto fabrics was delayed(as we wanted to make sure everything was working before committing to them), but that should happen without much problem next week) So in effect next week I am hoping to get the sensor data communicated via BLE to our webapp, and I am going to work with Rachel to get the sensors attached to fabrics so that it can be ready for the demo. I will likely also experiment with making sure the batteries we got provide sufficient power to our device.

Sydney’s Status Report for March 18

This week I worked on the Ethics assignment, as well as beginning work on the hardware interface. Our boards finally arrived, yay! So far I have managed to get the basic example working, meaning that we can read sensor data from the IMUs. I am still working on getting the on board quartenion processing working. I also worked on configuing the boards bluetooth to work with our web application, which created a potential concern for me. The Arduino web bluetooth library and the DMP library together might occupy all of the on board arduino memory without even including anything extra for our program. So this is something I am going to start investigating next week when I will probably try and combine the two. Worst case scenario, I think we will just offload the quaternion processing to the web app. On the github, you can see the work I have done / played around with under ‘hardware’. Looking at the schedule, while I am currently behind, I think I will be able to catch up next week as configuring the sensors doesn’t appear to be as much of a problem as we originally anticipated.  As I did meet the goal of reading data from the devices this week. Next week it shouldn’t be much of a problem to get the IMU’s placed onto our fabrics.  I will also try to get the MUX working so that I can read data from all of the sensors, not just one.

 

https://github.com/jasCode-s/liftOff

Sydney’s Status Report for March 11

This week I primarily worked on the Design Review Report. This was helpful in forcing me to think even more about our design. I also placed the order for our batteries as well as the fabrics we are going to put the device on this week. Outside of the design report, I wasn’t able to get much done because I am still waiting for the parts to arrive. I am starting to get pretty concerned about this.  I am not sure that we have any back up plans for if the parts take much longer to arrive. Finishing this up at the end of spring break, they are still not in, so we will begin reaching out to the appropriate resources and potentially looking at ordering from a different vendor with rush shipping on Monday. We are falling behind schedule, but this week I will work on connecting the arduinos to the web app as we don’t have the IMU’s yet, which will let us get rid of some interfacing time at the end(hopefully).

Sydney’s Status Report for Feb. 25

This week we placed the parts order from the budget / part list. I also assisted with making the teams design presentation this week, drawing up circuit/sensor schematics. As we are still waiting for parts to arrive, and as this is a heavy midterm/project week for me, I did not get a ton done. I briefly explored some arduino code that might be useful for interfacing with my desired parts. In particular, I am focusing on learning how to use the ICM-20948 Inertial Motion Units as those are more critical to our MVP, while the foot pressure is a nice to have.  In particular, I looked at this library and thought this code example might prove relavent: https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/main/examples/Arduino/Example9_DMP_MultipleSensors/Example9_DMP_MultipleSensors.ino

Originally, I was planning on trying to write out some code for my use case, but I think it might be more worthwhile to just try and test one at a time, then build out from there. I also looked into how to use Bluetooth Low Energy on an arduino, as I am afraid that could prove problematic later on, and would rather at least learn a bit now. So I read this article on it. https://docs.arduino.cc/tutorials/nano-33-ble-sense/ble-device-to-device

 

Unfortunately, I feel like I learn best by doing, so for now I just gathered resources to use next week when the parts arrive and I have the opportunity to work through some of these tutorials.  I am a bit behind schedule as we were hoping to have the back sensing and weight sensing devices built by now. However, I think it will be okay, as I have done thorough research and planning, so once the parts arrive, assembly should not take long. My plan to catch back up is just to make sure the “ensure everything works together” part of my task list goes smoothly (which it should as I put in plenty of research into my part configurations beforehand)

So next week I am hoping my parts will arrive and I will be able to check off my assembly and data collection from device tasks.

Sydney’s Weekly Status Report Feb. 18

This week I worked primarily on finalizing the current design of our device. I am a bit behind schedule, in that I did not finish my design planning early enough to place the part order last week. I don’t think this will pose too much of an issue, as the order will hopefully go out next Tuesday, and I can use that lead time to start writing some arduino code to interface with the controllers such that as soon as they arrive I will be able to start testing. The ECE course that helped me to develop this design is primarily 18-220 and 18-100, which gave me basic knowledge around using sensors and arduinos, supplemented by reading lots of tutorials about inertial measurement units on the internet.

Aside from working on the hardware components, I also assisted with making slides / graphics for the design presentation. Next week I hope to get the parts in, and hopefully start testing by the end of the week, but if they don’t arrive in time, I will refine the design for the foot pressure sensing unit. This is because at this time, I was focused primarily on getting the more critical back unit done(as this is somewhat a blocker for Jasmine’s work on back orientation detection until we know what data we will be able to collect).

 

Here’s a link to the sheet I used to plan parts. https://docs.google.com/spreadsheets/d/19h7SsfZl7L6Hj6JMvvSDONWY2HEp8ZFq5vFqzvN0bgU/edit?usp=sharing

 

Sydney’s Weekly Status Feb. 11

To start off the week, I spent a good deal of time practicing and preparing for my proposal presentation. I refined my talking points to make sure it would fit into 12 minutes, as it was originally sometimes 15!

Having given the presentation, I spent the rest of the week researching sensor options. In my sensor research, I learned that you can only hook up a single MPU6500 combined gyroscope accelerometer to a Arduino at a time(there is perhaps a way to communicate multiple over the bus, but this is beyond my current analog device knowledge). With this limitation in mind, I decided to start looking at bluetooth enabled sensor units instead. This led me to two options, the MBIENTLAB MotionRL sensor for $110 per unit, and the WITMOTION sensor at about $50. While the WITMOTION sensor is cheaper, the MBIENTLAB sensor has much better documentation, and has clearly been used in developing other applications. It also includes a magnetometer, which prevents angular velocity drift. I believe this will be helpful in limiting potential data collection errors later on.  It also provides a much larger range of support than the WITMOTION sensor, allowing for low power consumption modes, and a battery life of up to 14 days. For this reason, I currently believe it is the clear choice. I am not currently behind schedule. Next week, I intend to actually order the sensors, as well as begin writing some code to communicate with the sensors so that once they arrive I can immediately begin experimenting with their functionality.

 

Link to reseach doc:

https://docs.google.com/document/d/1jEEZFMm4V-nKgTUkH4GX_SufVJgoKhpiRbq81Mextvg/edit