Author: gmliu

This week, my group members and I carefully reflected upon previous feedback from peers and faculty to curate a cleaner and informational presentation. Because we have made some significant progress in meeting our target goals every week and have made a few design changes, it was a bit more difficult for Surya to include everything in under 12 minutes for the design presentation. Nonetheless, Surya did a great job of addressing previous concerns from peers (i.e. clear definition of MVP and quantitative design requirements from the user perspective) and reporting design progress. A lot of our progress and discoveries made during the process helped us visualize the bigger problem and additional factors that would need to be addressed in our design report.

In terms of our web application, after viewing other group’s presentations and use-case requirements from the perspective of their users, I focused more efforts on designing frontend that would be easy to use as well as attractive to our typical user. I started creating better mockups for the pages I have in views.py and HTML pages (user login, user profile, and user home page). Tabs/buttons that should be included on every page for user accessibility are the home page, a user guide that will have details on how to maximize the use of our product, perhaps (to attract more users) have a leaderboard of daily calorie intake between users in the same household, and a logout button.

I am a little behind on schedule as the goal was to have most of the frontend without backend connections from Steven and Surya to be completed soon. Next week, I plan on reflecting upon changes we may want to add to the user interface with my group members and complete the rendering functionalities between different HTML pages. With the design report being due as well, I plan on creating specific system implementation diagrams with changes derived from more recent testing operations.

This week, I focused more on building functions in views.py for incoming HTTP requests and responses and different HTML pages corresponding to user login, user profile, and user home page. While the rendering functionality has not been completed yet between pages on the frontend side, it is essential to build the views.py functions as it directly connects user web requests to a lot of backend logic in Django. In addition to this, since we were able to receive a lot of insightful feedback from the faculty and our peers on the proposal presentation, we worked together as a group to reflect on potential changes for the design proposal. I realized there were several things I overlooked while preparing for the previous presentation, so I wanted to go through them with Surya to ensure we meet the new requirements and fully demonstrate understanding of our project design.

Within views.py, action functions check if a user profile exists and whether or not it has been completed (so far, fields to be checked include name, gender, weight, and profile picture). I also included corresponding functions for the rendering of user login, user profile, and user home pages in which the latter two can only be displayed once a user is logged in. A convenient way to handle user login and registration is the forms.py module. This can authenticate the user’s username and passwords, otherwise, throw an error on the frontend side. We want to render these webpages if a GET request is detected.

More testing will have to be done with the HTML pages to ensure they meet our end goal aesthetic in CSS and JavaScript. Each page is built upon a base.html file that includes our product name display, user profile button, logout button, home page button, and daily intake button. This allows ease of navigation between pages for usability and helps us ensure consistency during testing phases.

Moving on regarding previous feedback, a big thing I failed to pay more detail to was defining MVP since these questions arose during the Q&A session. In next week’s presentation, we will clearly define the differentiation between image classification/label reading and scale reading foods in the testing and verification requirement. Although there was a mockup CAD to help explain the entire process of how users would utilize our product, we could have included more use-case requirements from the user perspective in addition to the product design perspective. We made the addition of including latency minimization to ensure data is forwarded to mySQL DB at a reasonable rate. There is also more specific quantitative data to demonstrate the viability of our idea. Surya will included changes in the design presentation to ensure questions from the feedback regarding our implementation will be addressed.

While we did include an overall flowchart in the proposal presentation, we noticed a lot of other groups included a block diagram that either showed an overview of the interaction/connection between interfaces or separated their components into hardware and software parts. Since our implementation has a clear separation between the two components, I thought this conceptual block diagram would be the best approach. Our first block diagram separates our hardware and which software integration fits under them with a clear overall flow. As seen below, the implementation plan includes more details including our software design/development, off-the-shelf parts, and where the user will be interacting with our product:

The CAD design has been updated to include our main design changes:

• Replacing the Arduino camera with an Arduino driver/receiver that directly forwards scale measurements to the cloud as opposed to adding light illumination inside the box as well.
• Using a ring light to ensure full illumination of classified object.
• A hinge mechanism on the door for better user accessibility and help audience understand product use.

We look forward to presentations next week that while not only will address most people’s confusions but also give us more guidance on our ambitious goals for designing a useful product.

During this week, I presented for my group’s proposal presentation on Monday. My group and I initially worked together to expand on some of the ideas from our abstract and accurately reflected them onto the required themes of the presentation. I was then able to elaborate on the slide requirements to help the audience better gauge our product use. Since we had already established our problem and solution requirements, reasonable quantitative metrics were defined that state facts about our system.

Using the hardware components my team members scoped out, I was able to sketch a mockup of our envisioned product in CAD with the corresponding dimensions to be included in our solution approach. I believe this was an important step to visually demonstrate to our audience how users would utilize our food tracking product in realtime. Afterwards, the steps to the project were split into three different components that could be worked on asynchronously: image classification, storing scanned information to a cloud database, and the website interface for users to interact on. 

Moving onto technical challenges and testing verification, communication between each component would be hard to achieve in an efficient manner since image classification, scale weighing, and forwarding backend calculations to the database would all need to be processed and displayed in a relatively short amount of time. There also exists the decision of choosing between a wireless implementation or connecting our hardware to be offloaded to a computer for debugging purposes. We will decide between the two upon further testing. In parallel to the steps of our solution approach, verification and metrics were defined to guide our initialization process.

In terms of progress, I am on schedule with what I wanted to accomplish this week. However, upon receiving feedback during our Q&A session and overall notes from the faculty, there are many additional factors that need to be considered. I will need to review more on the technicalities of the OCR algorithms we will be testing with. Additionally, we have established that cooked meals will not be part of our testing plan and our product serves more as an inventory tracker for food.

A mockup of the website framework has been created that allows users to login through either a new account or Google OAuth. At the moment upon logging in, there is dummy data that will eventually be the food items users scan in. I plan to add functionality that lets users delete food items as they desire to be added to the total macronutrients count. Also, my group and I may discuss more on how interactive we would like to make this user interface and ask Professor Savvides for additional feedback.