Nina Duan’s Status Report For 2/25/2023

Personal Accomplishment

On Wednesday, I presented my group’s design review presentation and received valuable feedback.

After following up on our request for AWS credit, I was told that we should use a free, open source database instead of AWS DynamoDB. As a result, I spent some time experimenting with Replit, the database an instructor recommended, and Redis. However, the free version only allows us to create public repositories, which could result in academic integrity issues, so I ended up choosing Redis. While Redis is built to support storage of complex data structures, it works perfectly well with small-scale, simple key-value pairs we are planning on storing, too. In addition, because it is an open source database, there are many sample projects and usages that we can draw inspiration from.

As of now, I have finished setting up the cloud database and written skeletal Python code for simple data insertion, removal, and modification.

I will follow up with a more detailed storage model design in my next status report and our design review report.

About Schedule

Since we switched to Redis Database in the middle of the week, I have fallen behind schedule. However, because our project only relies on a few basic functionalities that are common among most noSQL cloud databases, this change won’t require a drastic change in our design.

Plans for Next Week

Other than crafting the design review report, I will create object classes representing customer orders and related subcategories in Python, which will match how they are stored in the cloud database. Completing this will allow us to integrate the cloud database with our NLP algorithm, which Lisa is still in the process of fine tuning.

Team Status Report For 2/25/2023

Teaming

This week we have made a Github repository for our project’s code files.

Each member has made progress on some of the assigned tasks, which will be explained in detail in everyone’s status reports. A simple version of the natural language processing system has been created; it is able to detect menu items based on basic sentence structures (such as “I want one hamburger” / “A cheeseburger, please”), and we are still in the process of debugging and determining the ideal approach to process more complicated grammar structures and tackle edge cases.

While working on our individual tasks next week, we will write the design review report together.

Risks

The most significant risk is falling behind the schedule for our project, since most of the work is taking longer than expected. We will make sure to allocate enough slack time before the final deadline to accommodate potential schedule changes. We also have decided to continue working on the project over spring break to make more progress.

Design Changes

Since it’s unlikely that we will be able to get AWS credit through the capstone course, we plan on switching our cloud database to Redis. We also considered Replit, which an instructor suggested. However, the free version only allows us to create public repositories, which doesn’t satisfy one of our basic requirements. Fortunately, this change doesn’t affect our design much as our project only relies on a few basic functionalities that are common among most noSQL cloud databases. In addition, since we have a few spare infrared sensors, we might be using multiple sensors to detect the presence of a customer in order to increase detection accuracy. 

Schedule

We have updated our schedule according to the current week’s progress.

The setup of the infrared sensor is shifted to an earlier date since the Raspberry Pi has already arrived.

The natural language processing system is taking longer than expected to program, so we have extended the timeline for a week and will potentially still work on polishing it when integrating the database and NLP system.

Shiyi Zhang’s Status Report for 02/18/2023

Related ECE Courses

I learned about modularity and ethics in 15-440 Distributed Systems, 17-214 Principles of Software Construction, and 17-437 Web Application Development. An example of using the modularity principle would be that, when designing a distributed system that involves clients, proxies, and servers, it is important to divide the system into separate, independent components or modules. For our project, we have divided the system into speech recognition (backend), motion detection (backend), database (backend), user interfaces (frontend), and hardware components such as microphones and infrared sensors. Each person in our team is responsible for one or more of these modules.

Personal Accomplishments

One of the tasks assigned to me was to make the infrared sensor work with the rest of the system. The sensor should signal the Raspberry Pi when a customer is within 0.3 – 1m away from the kiosk.

HC-SR501 PIR sensor (front & back)

After doing some research, I made a list of hardware components I needed:

1 x HC-SR501 PIR sensor

1 x 830-point solderless breadboard

1 x Raspberry Pi holder compatible with Raspberry Pi 4B

1 x T-shape GPIO Extension Board

1 x 20cm 40-pin Flat Ribbon Cable

5 x HC-SR501 Motion PIR sensor

Resistors

Jumper wires

I ordered them online, and they arrived this past week. I brought the Raspberry Pi home with me from the class inventory and spent Friday assembling them.

The next step was to write a Python script that would allow us to visualize when motion is detected. I downloaded the Thonny IDE and used it to write the code because of its vanilla-like interface.

import RPi.GPIO as GPIO 
import time

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
PIR_PIN = 23

GPIO.setup(PIR_PIN, GPIO.IN)
print('Starting up the PIR Module (click on STOP to exit)')
time.sleep(1)
print ('Ready')

while True:
    if GPIO.input(PIR_PIN):
        print('Motion Detected')
    time.sleep(2)

It prints “Motion detected” when the sensor detects movement (condition applied). Along the way I discovered a few places that caused bugs and fixed them by:

  • Giving a 1-sec sleep to settle the sensor before entering the infinite loop.
  • Giving a 2-sec sleep in each iteration to avoid multiple motion detections. 

After running this code, the shell should look like:

On schedule?

Yes, my progress is on schedule.

Deliverables for next week

It doesn’t make sense to add more code for the sensor until the backend is a bit more developed (currently at the design stage). Therefore, I will move on to working on the frontend (customer UI & staff UI). I will be discussing with Lisa, who is responsible for the speech recognition part, about what to display on the web pages as this is semi dependent on how & how fast speech is parsed.

Nina Duan’s Status Report For 2/18/2023

Principles of Engineering, Science, and Mathematics – Relevant Courses

Many courses touched on the importance of ethical considerations in engineering. For example, both 18-100 and 18-500 had slides dedicated to the societal/economic/environmental impact of engineering.

Modularity is also emphasized in many ECE and CS courses. Project-heavy courses such as 18-341, 18-349, 15-445, 17-214 especially focused on this, since modularity makes a large project more testable and maintainable.

Personal Accomplishment

For the first half of the week, I focused on researching microcontrollers and databases.

In the end, my teammates and I decided to use a Raspberry Pi for speech recognition because it can interface with sensors and microphones and has CPU and memory powerful enough to drive a speech recognition algorithm. I also found some sample projects that use a Raspberry Pi for signal processing:

I focused my database research on comparing Amazon DynamoDB and Redis:

DynamoDB Redis (Remote Dictionary Server)
General Commercial system (pay) Open-source, can be used for commercial purposes
Storage Model Key-value

Document model

Key-value

Secondary database models: document store, graph DBMS, and spatial DBMS

Partitioning Sharding Sharding
Performance 20+ million requests/sec

R&W fast regardless of table size

In-memory database (requires large amount of memory to run quickly)

Optimized for complicated data structures

Durability & Availability 3 separate zones

Data still available even if one zone goes offline

Open-source version not very durable (diskless DB)
Security Encryption No encryption
Use Cases Applications that require high-speed data writing and reading Session cache, chat, messaging, and queues

Geospatial data, live streams, and real-time analytics

Pricing On-demand mode: based on number of accesses Free, open-source

For now, we are planning on using DynamoDB because our project requires fast insertions and deletions but not complex data structures. The final decision will, of course, also depend on whether we’re able to get AWS credit through this course.

For the second half of the week, I worked on preparing for the design review presentation.

About Schedule

I am on track with our schedule. In fact, we were able to get a Raspberry Pi 4 and start playing with it ahead of time.

Plans for Next Week

I will be presenting our design in class.

In addition, I will discuss the potential of getting AWS credits with the instructors and start familiarizing myself with DynamoDB’s APIs.

Once we review design review feedback, my teammate and I will also place orders for the hardware components.

Lisa Xiong’s Status Report For 2/18/2023

Personal Accomplishments

This week, I completed research for the microphone and sound shield we need to purchase. We will proceed with Neat Bumblebee II and Moukey Microphone Isolation Shield. Both received a lot of positive customer feedback on Amazon and can arrive within 5 business days once the order is placed. Neat Bumblebee II is one of the only USB-compatible desktop directional microphones that can rotate vertically, allowing us to accommodate customers of different heights and with accessibility needs. According to past customers, it is also proficient in filtering out background noises. The Moukey Microphone Isolation Shield has 5 foldable panels, which can turn it into a semi-parabolic sound shield if necessary. I also added backup options for both microphones (Blue Yeti) and sound shields (IDoon or Aokeo) in case these two cannot satisfy our requirements after testing.

To prepare for the upcoming design review, I collaborated with my teammates to design the block diagram. I was also in charge of writing user requirements and solution approaches for the speech recognition system, and modifying our Gantt Chart schedule. Moreover, I have started doing research for implementing the natural language processing system next week.

Relevant Courses

Natural Language Processing (11-411) helped me to come up with the natural language processing pipeline for our project. Web Applications Development (17-437) which I’m taking this semester allowed me to brainstorm ideas for the kitchen-side user interface.

Schedule

According to our plan, preliminary research is to be completed by 2/19/2023, and I have done the required research for hardware components and libraries. One modification we made on the plan was that we will wait for the feedback from our design presentation to purchase the parts instead of doing it this week. Overall, I am on track with our schedule.

Plans for Next Week

I will start programming the natural language processing system that converts text to menu items next week. By next Saturday, my program should be able to identify order items in text input with around 70% accuracy.

Team Status Report For 2/18/2023

Principles of Engineering, Science, and Mathematics
  1. Modularity – We broke our design down into smaller chunks that each manage a cohesive group of tasks. For example, the program that runs on the Raspberry Pi consists of two modules: one monitors the infrared sensor and wakes up the main backend loop; the other manages the heavy-lifting for speech parsing and recognition. These modules can further be broken down into submodules such as signal processing, speech-to-text translation, and text parsing (NLP).
  2. Ethicality – One of the main goals of our project is to improve the welfare of fast-food restaurant employees. We believe that the success of our system will alleviate the burden of kitchen staff, enabling them to focus only on preparing food. Our infrared sensor and ordering station will also accommodate customers in wheelchairs as well as children.
Risks

Since we are still in the design phase of our project, the most significant risk that could jeopardize its success is failing to consider important design requirements, which would lead to fundamental flaws in our design. To mitigate this risk, we will carefully review feedback from our design presentation and discuss potential problems with our instructors.

Design Changes

We finalized our design for the design review presentation and created a system diagram for the current design:

We have already requested and received a Raspberry Pi 4 with 8GB memory from the ECE inventory. Once we present our design and receive feedback, we will start ordering the hardware components (infrared sensor, microphone, and sound shield).

Schedule

We reformatted our schedule and took spring break into consideration. 

Here’s the updated version:

Shiyi Zhang’s Status Report For 2/11/2023

This week I have been primarily focused on researching sensors for detecting the presence of a customer), as well as the most suitable programming languages to use for the Raspberry Pi and the frontend.

Sensors

Passive infrared (PIR) sensors are well suited for our project, because:

  1. While active infrared sensors are more versatile than PIR sensors, as active infrared sensors emit their own infrared radiation and therefore can detect objects and motion even in complete darkness, food-ordering kiosks do not require such capabilities. In fact, fast food restaurants are usually brightly lit environments, so there is no need for that level of sensitivity. Therefore, we will be using a PIR sensor, which detects the presence of a customer by measuring the changes in infrared radiation in the environment. The change in infrared radiation will trigger the PIR sensor and cause it to output a signal. 
  2. They are low-cost, easy to use, and widely available, so they should save us some budget. Plus they have extensive documentation available online.

I have narrowed our options down to three:

  • HC-SR501

Low-cost, widely available. Can detect movement within a range of 7 meters and has a built-in potentiometer that can be used to adjust the sensitivity and trigger delay time.

  • Parallax PIR Motion Sensor

Designed specifically for use with microcontrollers like the Raspberry Pi, which we will be using! It has a range of up to 20 feet and provides a digital output that can be easily read by the Raspberry Pi.

  • Adafruit AMG8833 IR Thermal Camera Breakout

A more advanced option than the previous two. Provides not only motion detection but also thermal imaging capabilities. It can detect the heat signature of a customer and is ideal for applications where temperature info is also needed.

Programming language to use for the Raspberry Pi

A variety of programming languages can be run on the Raspberry Pi. I have narrowed our options down to:

  • Python: the Raspberry Pi has a strong emphasis on Python and is the most widely used language on the platform.
  • C: provides more control over the hardware (in our case, the PIR sensor), and it is fast, efficient, and uses minimal resources, so probably won’t heat up our Raspberry Pi too much.
Front-end languages/frameworks

I have narrowed our options down to:

  1. HTML + Bootstrap/CSS: we can utilize Bootstrap templates shared by people online. This saves us a lot of time and the result is visually appealing. However, due to the nature of Bootstrap, the HTML code can become quite cluttered and difficult to manage.
  2. React: uses a declarative programming approach, which makes it easier to understand and debug. The use of reusable components can be easily reused across different parts of our front-end development.

About Schedule

My progress is on schedule.

Plans for Next Week

I will start front-end development and create a list of sensors/ microcontrollers to purchase. Additionally, I will work with my teammates on creating the slides for the next presentation.

Lisa Xiong’s Status Report For 2/11/2023

Personal Accomplishment

I mainly focused on doing research on the sound shield and speech processing system this week to prepare for our upcoming design presentation.

Since the height of our microphone will accommodate customers both standing and in wheelchairs, our system will require a wide sound shield with an adjustable mic stand. I have found some suitable options on Amazon and plan to discuss with my teammates before purchasing one.

We plan to use Python as the programming language for our speech recognition system, since it is both compatible with natural language processing libraries — such as spaCy and Stanza — and has an open-source speech recognition library. For speech recognition, I found the python SpeechRecognition library, which works with external microphones. For natural language processing, although the tokenization accuracy of Spacy and Stanza are similar after some experiment, we decided to proceed with spaCy since it is faster and has more documentation for us to learn the functions.

About Schedule

Since we have scheduled two weeks for preliminary research (i.e. to be completed by 2/19/2023, the due date for our design presentation), I am on track with our schedule.

Plans for Next Week

I will purchase the sound shield, mic stand and microphone by the end of next week to make sure they arrive in time for our hardware assembly. As the deadline for design review is approaching, I will also work with my teammates to finalize our system design, and make slides for the presentation.

Nina Duan’s Status Report For 2/11/2023

Personal Accomplishment

This week, I mainly focused on conducting research for our proposal use-case requirements and some components necessary to achieve them.

To properly quantify our project’s service expectations, I took a look into research about service times of existing fast food restaurants and found this 2016 research by QSR Magazine particularly interesting. Although it is about drive-thru service specifically, the research data does suggest that customers expect an average service time of about 200 seconds. A news report from 2020 claims that drive-thru has been slowing down in recent years, which means the expectation nowadays could potentially be even lower.

To achieve our use-case requirements (see proposal), we need one or more directional microphones that can receive verbal inputs from a distance of 0.5m to 1.0m. They will be driven by a Raspberry Pi or an Arduino, which requires USB or I2S connectivity. Here’s a list of some options I’ve found so far:

  • WM8960 I2S Microphone
    • Raspberry Pi connectivity, compatible with Raspberry Pi Zero/Zero W/Zero
    • WH/2B/3B/3B+
    • Comes with demo and development guide in Python
  • MP34DT01 I2S Microphone
    • More compatible with Arduino, includes device-specific library
    • CircuitPython module (in Python, C)
  • Samson Go USB Mic
    • Compatible with with Raspberry Pi and laptops (Mac & Windows)

In addition, I also took a look at available commercial databases. In our proposal, we chose to use noSQL cloud database, which leaves us with two prominent options:

  1. AWS DynamoDB: fast insertions and deletions, but less customizable and structured
  2. Redis: supports secondary database models like the document store, graph DBMS, and spatial DBMS
About Schedule

Since we have scheduled two weeks for preliminary research (i.e. to be completed by 2/19/2023, the due date for our design presentation), I am on track with our schedule.

Plans for Next Week

I hope to finalize our microphone, microcontroller, and database selection by next Wednesday, which will allow us to finish our design and start gathering chosen components. I will also be our group’s presenter, so the rest of the week will be spent on polishing our presentation slides and preparing for Monday’s presentation.

Team Status Report For 2/11/2023

Our project includes considerations for customer convenience, employee welfare, and restaurant cost reduction. Our system will provide an alternative ordering approach to fast food restaurant customers, and reduce the number of cashiers required. This could also improve existing employees’ working conditions, as they no longer need to shuffle between the counter and the kitchen and can focus on food preparation.

This week, we updated our Gantt Chart to increase slack time at the end of the project timeline. This time will allow us to conduct more end-to-end tests if necessary and fix unexpected issues with our final product. We also created preliminary designs for our whole system, separating the system into hardware, front-end software, and back-end software components. Use-case requirements and testing metrics were updated based on our research about existing fast-food services and hardware systems. Next week, we will finalize our design, prepare for the upcoming design presentation, and start gathering necessary project components.