Feb 17th 2024 Status Report — Surya Chandramouleeswaran

My roles this week involved a dive into the design process in preparation for the upcoming design presentations. In particular, I decided to take the opportunity to present our team’s design plans next week. Preparing for this presentation requires strongly re-evaluating current project parameters and scope. Additionally, we found the feedback from our peers and faculty quite valuable from the proposal presentation, and we are eager to reflect on their suggestions in our design process. Building these slides, in concert with feedback and an improved understanding of our project, forced our group to critically examine every component that we plan to develop, in the hopes of convincing our peers of the value of our product and the merits of our implementation approach.

For my specific role in the project, I started looking ahead into scale integration. Learning the requisite communication methods was a focus of mine this week, especially in the context of seamless integration with mySQL. I came up with 3 proposals, weighted carefully for their relative merits and drawbacks:

  1. Arduino RS-232: There is a lot of support for this chip, which serially communicates the weight reading to a computer through USB. This approach would involve a fair amount of scripting to implement a “polling feature” that Prof. Savvides and our group discussed this week in our meetings. In particular, the code would need to sample the weight reading at a high enough frequency (possibly every second) to detect significant weight changes, to then write to the database. Although this is a good starting point for the project and is largely scale-choice invariant, I am not too fond of this approach given that RPIs are a little easier to work with in this context than Arduinos, and the fact that a USB connection may be rather unwieldy.
  2. ESP-8266: This option was one that I had to do a bit of searching for, but this chip works quite seamlessly with mySQL. Along with the scale and the chip, the final design would presumably involve a load cell amplifier, 5-volt power supply, and jumper cables to hook everything together. The chip would have to be controlled through PHP code, which is something that I would need to familiarize myself with, and the documentation/support is not nearly as good as it is for a product like Arduino or RPI. Much like the previous example, it functions as a good proof-of-concept approach.
  3. Xiaomi Smart Scale with Bluetooth RPI communication: Also works seamlessly with mySQL, and has the benefit of being a Bluetooth communication in terms of elegance, but requires most implementation and background knowledge to successfully build. Some of the challenges include proper recognition of the MAC address of the Bluetooth dongle (for the program to recognize the RPI), and some additional code for the busy-polling feature we would like to implement.

 

My preference is to leverage one of the first 2 options towards a working idea, and then, maybe as a stretch goal, work with my teammates to getting a Bluetooth communication setup working. It would greatly improve the aesthetic of the project and would automate several of the features we are looking to incorporate.

 

As a group, we started laying the groundwork for our project’s essentials, and I helped across the scope for such collaborative ventures: exploring image recognition and classification architectures with Steven, to working with Grace on backend deployment. Grace’s expertise in local deployment (learned from her web applications course) gave us a proof-of-concept idea of deploying a scalable application through DB.sqlite3. We are debugging some of the view actions as part of the MVC architecture, and remain committed to our goal of transitioning to a flexible mySQL database. One of the main things we learned about is the importance of the database in achieving our latency goals. Updating and reading from this database are operations that should fit within our overall latency requirements of 30 seconds or less. Steven has expertise in efficient database manipulation and traversal, and I look forward to working with him to ensure the complexity of database traversals can be done in logarithmic time as opposed to linear. We plan on leveraging the fact that mySQL organizes workbench data as an object hierarchy (GRT Tree), which should go a long way toward efficient traversal and manipulation.

 

We look forward to design presentations this week as the semester begins to unfold.

Leave a Reply

Your email address will not be published. Required fields are marked *