Product Pitch

Team B1 : ChaseMe Alarm Clock

Can’t wake up on time for your zoom meetings? Our team is building a no-snooze alarm clock that you have to catch to turn it off.

All you have to do is to set an alarm through our web application. When it is time to wake up, your Roomba’s alarm will start ringing. As you approach and try to catch it, it can recognize you through face detection and move away from you. The alarm and movement will only stop when you back it into a wall. It is environmentally aware, so you don’t worry about it bumping into and damaging your furnitures. You can also also customize your ringtone on our web application.

If bright light, loud noise, and solving puzzles do not do it for you, try catching our robot chicken.

 

Yuhan Xiao’s Status Update for 12/5

Over the thanksgiving I decided to keep using NoSQL instead of switching to SQL databases. The advantage of NoSQL is that it allows room for future development, e.g. if we want to create a “big ringtone” – one long ringtone consists of 2-4 (original) ringtones (because one original ringtone is confined to up to 16 notes by Create2 Open Interface), is way harder if using fixed data schema in this case. It also allows us to change directions during our course of development with its dynamic schema. Besides, we don’t need any advanced filtering or querying, e.g. the most “advanced” filtering is probably filtering alarms by a specific user ID to get private alarm data of a user, other than that it is usually just “get all ringtones” or “get all alarms”.

Deliverables completed this week:

  • continued testing communication between Pi and web app
    • implemented a logging feature for myself to keep track of the messages sent from web app to Pi
  • implemented user login
    • users can now only view their own private alarms, but both public and their own private ringtones
  • implemented alarm deletion
    • tested by validating the logs after manually creating and deleting alarms
  • implemented ringtone deletion
  • deployed website using pm2
    • alive on http://ec2-3-129-61-132.us-east-2.compute.amazonaws.com:4000/

Next Week:

  • complete final video + report
  • minor UI/UX touch-ups

Yuhan Xiao’s Status Update for 11/21

This week I worked on debugging my current web app implementation, to make sure the audio plays correctly when the user is editing the ringtone.

I modified code snippet to Pi to start testing the reliability of the scheduling functionality of the alarm. Specifically I am testing to see if the node-cron package is working as intended. I am conducting the experiment for at least one week, so the result will be out earliest by next update.

Per last update, I researched a bit more into the possible SQL database options. For now I am leaning towards spinning up a local MySQL database on the EC2 instance for storing the ringtone data.

I am currently on schedule.

This week(week of 11/16 – 11/22):

  • continue testing communication between Pi and web app
  • modify communication code snippet on RPi so it writes to files instead of printing to stdout(to keep a record of messages & when they are received, to validate reliability of the alarm scheduling)
  • research on database change

Next week(week of of 11/23 – 11/29):

  • continue testing communication between Pi and web app
  • implement database change
  • implement alarm and ringtone deletion
  • implement ringtone creation by importing MIDI files

Yuhan Xiao’s Status Update for 11/14

This week I helped Echo and Peizhi connect with and expand on the code snippet I wrote last week. The code snippet can receive and delete messages containing alarm data from the web app server in real time. For now it is live at http://3.137.164.67:3000/(only when I spin up the server). Echo and Peizhi expanded on the snippet so it can initiate the robot sequence when a message is received.

I helped debug authentication and connection issues with AWS SQS when running the snippet on the Pi. I also helped modifying API endpoints according to the requirement of the Create 2 Open Interface so the data received on Pi can be directly used for ingestion.

I set up IAM users for both Echo and Peizhi, just in case they need to access web server or SQS console when they are debugging in the future.

I tried to move web server from Amazon Linux machine to Ubuntu in an attempt to deploy the website so it is always live, using Nginx, PM2, etc. It did not work  in the end after a few hours of debugging. It might have something to do with my project file structure. I might look into other services that help deploy MERN stack application, or Node.js application, or readjust my overall file structure.

I am on schedule.

For system design changes: I am considering switching MongoDB out for Redshift/RDS/Aurora. Right now I have the full working implementation using MongoDB, but I am concerned it might be an overkill considering the simple structure and light load of the data we are working with. Hence I am considering switching from NoSQL to SQL databases.  And using databases provided by AWS family like RedShift might be easier for integration. I can even just use a CSV file to store the data.

This week(week of 11/9 – 11/15):

  • prepared for interim demo on Wednesday
    • cleared and prepared sample alarm and schedule data
  • deployed current implementation to EC2(Ubuntu)
  • tested code snippet on Pi
  • supported Echo and Peizhi in the integration of the code snippet into the main program running on Pi
  • set up access for Echo and Peizhi for easier debugging

Next week(week of 11/16 – 11/22):

  • continue testing communication between Pi and web app
  • modify communication code snippet on RPi so it writes to files instead of printing to stdout(to keep a record of messages & when they are received, to validate reliability of the alarm scheduling)
  • implement alarm and ringtone deletion
  • research on and implement database change

Week of 11/23 – 11/29:

  • continue testing communication between Pi and web app
  • implement ringtone creation by importing MIDI files

Yuhan Xiao’s Status Update for 11/7

As planned last week, this week I

  1. implemented the backend of web app, using
    1. MongoDB – for storing ringtone and alarm schedule permanently
    2. SQS – for sending data to Pi when an alarm is created
    3. node-cron library(nodejs) – for scheduling the data sending mentioned above, at whenever the alarm time is (and repeating the sending every week)
  2. for the frontend, switched the data store from local storage to actual  database in cloud using axios;
  3. wrote a code snippet that receives simple data from the web app backend in real time, which is to be incorporated with the main program deployed on Pi.

Code for web app is here and code snippet deployed on Pi is here(private repository, let me know if you need access).

I tested my implementation by scheduling an alarm clock through my frontend at about one minute later than current time, e.g. say at 10pm. I verified that the alarm got stored permanently by checking MongoDB Atlas. By the alarm, I mean the day, time and ringtone associated with the alarm set. I verified on the “alarm schedule page” reflects an updated schedule with the new alarm. I waited for about one minute, and then a message with the alarm data was sent from web app backend to SQS queue at exactly 10pm. Then a message is received a few seconds later, by the code snippet also running on my machine.

One change to my system design is that I will be scheduling alarms on web app server instead of Pi, since I noticed the node-cron library supports repeating jobs every week, which is exactly the frequency of a defined communication between web app and Pi. The library also seems to have a solid user base and well-written documentation.

The coding turned out to be a bit more intensive than planned, so I did not get to test the snippet on Pi, or verify if the same alarm can be reliably started the same time one week later. But overall, I am mostly on schedule.

In the next few weeks before the final demo, I am planning to set up a testing/measuring workflow(i.e. reliability/robustness/latency of communication between web app and Pi), and add more operations to be supported by the web app(e.g. alarm/ringtone deletion, ringtone creation by importing MIDI files).

This week:

  • implemented backend with MongoDB
    • web app data pulled from & stored to cloud
  • implemented communication between web app and Pi with SQS(message queue)
    • send messages on web app backend(javascript, scheduled by node-cron), receive and delete messages on Pi(python)
    • did not test it on Pi, used local machine instead

Next week(week of 11/9 – 11/15):

  • prepare for interim demo on Wednesday
    • deploy current implementation to EC2
    • clear and prepare sample alarm and schedule data
  • continue testing communication between Pi and web app
    • test code snippet on Pi
    • handle connection errors gracefully, especially for receiving messages
  • support Echo and Peizhi in the integration of the code snippet into the main program running on Pi
    • figure out a way to host the web app with minimum down time, and maximum secure access to EC2, MongoDB and SQS for Echo and Peizhi for easier development and debugging(e.g. maybe setting up separate user accounts for them)

Week of 11/16 – 11/22:

  • continue testing communication between Pi and web app
  • implement alarm and ringtone deletion

Week of 11/23 – 11/29:

  • continue testing communication between Pi and web app
  • implement ringtone creation by importing MIDI files

Yuhan Xiao’s Status Update for 10/31

This week I did some research as to (1) how our remote web app server can communicate with Pi (how alarm data is passed from one to another), and (2) how alarm data is stored. As a result of my research, I decided to make some adjustments to our current system design – (1) AWS SQS is used to send data from the remote server to Pi, and (2) cron jobs will be scheduled on Pi instead of remote web app server.

My reason for change (1) is that just having MongoDB is not sufficient for real time communication between Pi and the remote server; sure, when user created new alarm on the frontend interface, data can be sent to backend and stored to MongoDB immediately, but MongoDB does not know if and which alarm is created in real time, and hence cannot pass the newly created alarm data to Pi in real time. This means instead of Python Requests library on Pi, we will use AWS SQS Python SDK. And on the remote server, AWS SQS Javascript(Node.js) SDK will be used.

While change (1) is absolutely necessary, change (2) is more up for debate and can be changed back later on. I made this change because this way we say goodbye to the potential latency between web app and Pi whenever the alarm starts. We did not plan to schedule cron jobs on Pi initially because we wanted to make sure Pi have sufficient computing power to run the CV code efficiently; I checked that cron job does not use up much resources(so does connection with SQS), and especially since only one cron job is scheduled for one regular alarm, Pi should probably do fine.

I have some pseudo code for this approach at the end of the update.

Since I spent more time on research and some more on ethic readings, plus big assignments from other classes , I have only written some pseudo code instead of actual code. As a result, I am running a little behind my schedule this week, but I will make up for it next week.

My next week’s schedule is to turn the pseudo code into actual code, with the exception of the addToCron() on the last line of the pseudo code on Pi.

On Pi:

import boto3, logging
sqs = boto3.client('sqs')
q = sqs.queue('name')
while True:
alarmData = q.receive_message()
logging.info(alarmData)
q.delete_messge(alarmData["id"])
addToCron(alarmData["time"], alarmData["ringtone"])
...

On remote server(web app backend):

// mongoDB init
var mongoose = require("mongoose");
mongoose.Promise = global.Promise;
mongoose.connect("mongodb:<LOCAL HOST>");
var alarmSchema = new mongoose.Schema({
time: String,
ringtone: Array[int]
});

// SQS setup
var AWS = require('aws-sdk');
AWS.config.update({region: 'REGION'});
var sqs = new AWS.SQS({apiVersion: '2012-11-05'});

app.post("/add-alarm", (req, res) => {
var alarmData = new Alarm(req.body);
alarmData.save() // alarm saved for permanent storage })
.then(item => {
var msg = buildMsg(alarmData);
sqs.sendMessage(msg, function(err, data) { // alarm added to queue, which Pi can read from
if (err) { throw new Error('Alarm data is not passed to Pi'); }
});
res.send("alarm created");
})
.catch(err => {
res.status(400).send("unable to create the alarm");
});

const buildMsg = (alarmData) => {
var msg = {
MessageAttributes: { alarmData }, // payload
Id: "MSG_ID",
QueueUrl: "SQS_QUEUE_URL"
};
return msg;
}
...

Yuhan Xiao’s Status Update for 10/24

This week I finished all the other essential web app UI development(“create ringtone” page ). I also enabled local data to pass through between components(e.g. when you clicked submit on the form on “create alarm” page, it shows up on “alarm schedule” page, etc) by the use of component states and local storage. This means all pages can now load alarm/ringtone data dynamically.

This also means I am currently on schedule and the web app is ready for backend integration next week as planned.

Scroll down to the bottom to see screenshots of all 3 pages of the web app. But since there are musical components to the web app(e.g. when you create the ringtone, you can preview your ringtone or individual note; you can also preview the ringtone on “alarm schedule” page, etc, like what a normal built-in phone alarm would let you do), clone to this github repo(email me to grant you access), do “npm install” and “npm start” to locally host the web app. I realize ec2 instance shuts down my web app hosting after a while so if you want to interact with the web app, you need to clone the repo.

Here are a few things that did not really go as planned:

  1. Right now the “create ringtone” page supports a more narrow range of notes(6 octaves) than create 2 robot base can support(8 octaves). This is due to some problems with the audio playing library chosen, that after the 6th octave, it stops playing audible sounds. I did not have time to investigate into the reason yet, but since 6 octaves should suffice, I will look into this after backend integration, if I have the time.
  2. I wanted to make a more intuitive interface for “create ringtone page”, but since there is not enough time for it, I also have to put it in the backlog and look into it after backend integration(with database for permanent storage and with Pi).

My schedule(same as last week’s):

  • week 8 (this week):
    • create ringtone UI
    • pass alarm data from create alarm page to alarm schedule page
    • pass ringtone data form create ringtone page to create alarm page
  • week 9 (next week):
    • backend set up
    • connect UI with backend
    • connect web app with Pi

Yuhan Xiao’s Status Update for 10/17

I set up an EC2 instance and prepared it for web app deployment.

I worked on web app frontend and made UI for user to set time and choose from a list of ringtones. Feel free to try it out here (note this might be updated to display new UI next week). If you clicks on the ringtone name, it plays a short ringtone that is defined by an array of notes, and each note consists of pitch and duration. I  implemented a “fast selecting” feature(user can choose “weekdays” to auto-select all five weekdays, and vice versa) which is also pretty neat.

I wrote a short script for Pi to communicate with the web app on EC2 instance and receives sample ringtone data.

I also worked on some portions of design review report(overall & subsystem architecture, etc).

Other work I did:

  1. I looked into using AWS Amplify(versus EC2) as a choice of hosting the web app. It can allow me to deploy and publish my web app every time I update it using one console command. However in the end, I decided against it because I am not sure if and how to implement the alarm scheduling using Amplify (2) it requires using GraphQL and DynamoDB which I am less familiar with, hence longer time to ramp up.
  2. I checked out Typescript as a possible option for frontend framework language, and ultimately decided it is not worth since the frontend framework I chose lacks documentation for Typescript.
  3. I decided on Ant Design as the frontend framework since it covers all UI widgets I would need.
  4. I looked at a few node packages for playing audio from midi files. I realized I had some misunderstanding about what midi is and how some of the “midi player” packages work. In the end I decided to use a different package for playing audio than I previously planned.
    1. I used this for playing audio by specifying notes: https://www.npmjs.com/package/soundfont-player
      1. It is a lighter version of https://github.com/gleitz/midi-js-soundfonts
      2. I was gonna use https://github.com/grimmdude/MidiPlayerJS but it turns out it just translate a midi file into a sequence of json data, but not play the audio
      3. I was gonna use sample-player package but decided other packages have a bigger user base
  5. I realized the user might not want to create a new ringtone every time they set an alarm, so I made a new page that is not previously on the mockup for design presentation for users to make ringtones and then the ringtones will be updated on create alarm page.

Currently on schedule. My own updated timeline (before integration) is as follows:

  • week 7(here):
    • web app build and deployment set up
    • spike on communication between web app and Pi
    • create alarm UI
    • alarm schedule UI
  • week 8:
    • create ringtone UI
    • pass alarm data from create alarm page to alarm schedule page
    • pass ringtone data form create ringtone page to create alarm page
  • week 9:
    • backend set up
    • connect UI with backend
    • connect web app with Pi
  • week 10(demo)

Yuhan’s status update for 10/10

I mostly focused on design review presentation this week. In preparation of the presentation, I improved on current user flowchart and system interaction diagram, and fleshed out web app mockups. I also made block diagrams for hardware and CV/ML portion of the project, so we have a visual representation of the implementation plan and materials to work on for design review report.