FootFrame Log

Week of January 29: The team spent a few hours brainstorming ideas for the idea FootFrame - a project that will detect forces applied by each foot when squatting or jumping onto two force sensitive resistors, one for each foot. Our idea was then to take this data into arduino, and use arduino to calculate and display the difference in these forces to detect an imbalance. This idea stemmed from our interest in the medical health field, as we thought detecting an imbalance in someone's standing posture could help determine whether it's necessary to fix the imbalance. Following this, researched load cells and the circuitry necessary to complete this project, along the way we found the items we would need to buy, which allowed us to work to complete our project proposal for FootFrame.

Week of February 5: The team reviewed their project proposal and adjusted it to fit with the improvements suggested by Humberto's corrections. There was discussion with friendly TA, Will Luer, about the physical design of the project and its sensors. The group began its initial tasks as outlined by the Gantt Chart, including learning C, designing circuitry, and researching load cells. Already, there are some concerns about the material that will be used to focus the force onto the sensors. Also, the group considered ways to filter data from the sensors, specifically using a rolling average filter to average out a certain time's worth of data, as well as some basic ideas for the algorithm that will be used to compute the data. Next steps include researching deeply into load cells and which will be purchased, as well as the beginnings of learning C.

Week of February 12: The team conducted individual research and also worked to finalize the platform and budget... Team: The team still needed to finalize the budget, as the design platform wasn't specific enough (the details of what platform we would place over the sensors was missing). After some thought, the group decided that they would use wood, the details on from whom we would purchase are still being worked on. Additionally, the team recognized that we also had not gone in enough detail with discussing which interface we would use to display data. As of now, the team would like to use a computer, and have decided to research how they can do this.

Jessie: This week, Jessie decided to use CSE132's website and lectures to start learning the basics of C as well as using an Arduino. He's currently waiting on being able to take out an arduino to conduct some practice. In addition, he conducted research on filtering and decided that for FootFrame's data collection, he will test a rolling average algorithm to see if it will accurately deliver a good force reading (Credit to Will Luer for discouraging Jessie's original idea of using a varied form of clustering).

Isabel: This week, Isabel looked at different types of platforms to find which would be the best. After conducting research, Isabel relayed to the group that she thought we would be unable to use glass, as the ideal sheet size for our platform is around 1/2 inches in thickness. This size is not only scarce, but it is also expensive.

Adam: This week, Adam designed the layout for the platform as well as the circuitry for the Wheatstone bridge. Adam also did extensive research into a similar project that was already finished of a dog scale in order to get a better idea on what the physical / technical layout of our sensors.

Week of February 19: This week, the team decided upon the type of wood that is needed for the project (the base, the load sensor supports, and the top foot plate). Excursions were made to the machine shop and the art school wood shop looking for available pieces to use. This trip demonstrated that we would be unable to use wood solely from campus locations. As a result, we updated our budget to accommodate for the wood we need to buy for the top foot plates. Additionally, we updated the Gantt Chart to more accurately represent our plans for our project. Following this, we signed up for an evaluation with Humberto. During our meeting with Will, we finalized the budget and prepared to buy all the necessary pieces for the project. Within a week, they should be in and assembly will begin. Also, plans were made to begin 3D printing the sensor housing material, which will attach to the sensor support blocks.

Week of February 28: This week, the team cracked down on the beginning stages of production. This began with the ordering of all the parts listed on the budget from sites around the Internet. Soon enough, all of the electronics and wood pieces should be in the team's hands. Apart from this, the load sensor housings were printed. The .stl files were found online (designed by a SparkFun frequenter troubled with the inability to stabilize the load sensors, whose github can be found at https://github.com/bneedhamia/CurieBLEWeightMonitor). Following this, the .stl files were translated to .gcode by the team using Cura and then printed in the CAD Lab. While awaiting the arrival of the other pieces, designs were put in place for the load sensor support blocks. The design will hold the sensors above the electronics on the bottom plate and be attached to the bottom plate and the load sensor housings using bolts. A method to stabilizing the top plate on top of the load sensors was also developed this week. A plastic piece will be 3D printed and bolted down on the center of the bottom plate. Then, a bolt or nail will be driven through this piece in the bottom piece, securing it in place.

Week of March 7: This week, Jessie found examples of code for a running average and reading FSRs using analog reads with the Arduino. Jessie decided to post the code that he found on the wiki page to store for later, as he believed that the code he had found had the potential to be modified in order to be used for the project. The group also acquired some wood materials that would be made into the "holders" for the FSRs, the group plans to measure and cut these wooden materials and begin assembling them shortly. Jessie also learned from Humberto that the project needed a more concrete focus regarding the output that the user would receive from our project. From this, he decided that a very useful output would be to tell the user how much of a force difference there is between the two legs, and whether that difference is worrisome or not. This is beneficial information to the user (especially if they are an athlete), because if it happens that they put too much force on one side of their lower body, they are much more susceptible to injuries on that side. Jessie is currently determining an appropriate value that determines how "bad" the force difference is. Meanwhile, Adam was busy taking all of the sketched designs and inputing them into a CAD program. He used SolidWorks in the university's CAD lab. Images from these files were uploaded into the Wiki.

Week of March 14: Group took the week off for Spring Break, but while they were gone the physical parts for the project that were ordered arrived, and now the group will begin assembly.

Week of March 21: During this week, the meeting with Will led the group to reevaluate their position with the mechanical design. As it turns out, the load sensor holders found on the github in previous weeks will not work with FootFrame's design. Therefore, another method of housing the sensors will be designed and printed. Also, the method of stabilizing the foot plate (using a 3D printed holder and a nail) was adjusted. Instead of this complicated design, the team will build walls from wood to hold the foot plate in place. At this point, the team has almost all of the necessary materials to build the project. However, the foot plates themselves experienced some shipping difficulty. The company that they were purchased from seems to have botched the delivery, and the team is in the process of finding where the wooden plates were actually delivered. But after a healthy meeting, the team is ready to make a final pre-assembly push and assemble later in the week. Later in the week, Adam redesigned the sensor housing and printed the new pieces. The wiki page was updated to reflect these changes in design.

Week of March 28: This week began with Adam hitting the CAD lab to redesign the load sensor housing and proceeding to print out the necessary pieces. A few days after that, he and Will took to the machine shop to cut up the wood pieces necessary for the mechanical design. Everything was cut and drilled to standard, but nothing was assembled. While in the shop, the duo decided to wait on assembling the project until the specifics of placement with electrical parts was figured out. As a result, Isabel got a lesson from TA Andrew in soldering and completed much of the soldering for the project. What remains now is for the electrical setup to be assembled in tandem with the mechanical design. As this was occurring, Jessie was combing through online codes and information, as well as checking out the new Arduino Uno that the lab has provided.

Week of April 4: On the 4th, the team met for a late night engineering session. Adam and Isabel discussed the final details of the soon-to-be-completed mechanical design. Isabel proceeded to solder almost the entirety of the project together while Jessie worked away at trying different wirings and coding. Adam assisted where necessary. After hours of trying to get readings from the load sensors, Jessie was successfully able to get readings from the Arduino. Following this, the group reevaluated their situation. In the coming days, Will and Adam will return to the machine shop and put the finishing touches on the mechanical design. Jessie will make some finishing touches on the code and calibration, and the team will proceed to develop an interface. Later in the week, the team met with Humberto. This meeting was an assurance that although integration was almost complete, the project itself is far from over. After integration of the mechanical and electrical design is completed, the team will need to figure out an algorithm that will take the data from the sensors and create a useful reading for users. This will require a standard that depicts whether an imbalance detected by the project is acceptable or unacceptable.