Tag: sydney’s status report

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.

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

 

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