Milestone 3
Implementation
Sensor Technology Selection:
Methodology: In order to select the correct sensor for each stage of development of Contaxt, our requirements and needs must first be established. In the prototyping and initial design phase of Contaxt, quick development and rapid integration are vital. There are also some technical requirements that we must satisfy: the sensor must have a large enough dynamic range to allow us to accurately and precisely sample a reasonable floor and ceiling of human-kick levels of force. Form factor is another requirement, although not as important as the previously mentioned requirements. The sensor must be somewhat flexible and durable for the prototyping and early design phase. When it comes to the final implementation of a ready-to-sell product, the requirements change slightly. Quick development and integration is no longer priority, and the correct form factor requirement is more emphasized. The sensor, at the final stage of development, must be flexible and durable enough to last years, fit to different people's shins, and be able to work under wet and cold conditions.
Selections:
Early prototyping phase: simple FSR sensor with pinouts terminated at the end.
Pros:
Can implement a frontend circuit in order to amplify voltage across different levels of contact. Enough for us to be able to classify the force on the sensor on a scale from 0-7. This will simplify the implementation in software and present the data more succinctly.
Cheap and readily available. There is a possibility for us to damage the sensor, having the ability to order the sensor right away is very important.
Reasonable dynamic range.
Flexible and can be fitted to a customized package easily.
Final product development stage: Conformable TactArray from PressureProfile
Pros:
Associated MATLAB software tools for development will be very helpful for fine tuning the final product's parameters.
Extremely flexible and remains accurate when flexed.
Tested under wet/dry and cold/hot conditions.
Wrapped in a fabric, perfect for our use-case.
Fig. 1 Raspberry Pi and Wi-Fi adapter acting as the MQTT subscriber
Fig. 2 Arduino Nano with FSR sensor connected
via breadboard as MQTT publisher
Testing
Fig. 3 Arduino Nano soldered to FSR sensor
Fig. 4 Raspberry Pi reading data from sensor through MQTT server
Hardware Testing:
Hardware testing first started with assembly of the components on a breadboard to make sure that everything functions together. Then code was uploaded to the Arduino board to test MQTT functionality and send functions to the Broker (Raspberry Pi). The broker was running MQTT and received signals successfully as shown in the photo.
An MQTT Subscriber was created to test signal receiving functionality, written using the Paho-MQTT Python library. An HTML Webpage was created to display the data but is yet to be connected to the broker.
Software Testing:
Software testing consisted of confirmation of signal transmission and repetitive testing of the HTML webpage to ensure a good design.
Teamwork
Hardware: Christian mainly focused on the Arduino and force sensors for our project either at home or in the lab.
Software: Yazan and Eric mainly focused on the Raspberry Pi for our project in the lab.
Website: Zach mainly focused on formatting the project website with the teams inputting their testing processes.
Business Plan & Poster: Zach, Danny, and Isar mainly focused on this part of the project with collaboration from other group members.
Although we have specific roles according to our skills, everyone contributed to accomplish our deliverables, with most of the group sharing ideas at lab sessions twice a week during senior design.