Category: All status reports

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

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;
}
...

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