Ellen’s Status Report for May 1

We did a lot of testing this week. I was responsible for the transcription related tests so I spent time calculating word error rates, speaker ID error rates, and the like. The transcript latency test was fairly time consuming to evaluate as I couldn’t come up with a way to automate it but in the end there were a good number of samples and positive results.

I helped to prepare the final presentation slides this week. I also whipped up a script for the final video, and we got a lot of filming done today.

There’s not much else to report! I’m glad we pushed very hard to do a nice integration before the interim demo, so now we aren’t rushing to finish our MVP. Next week we’ll keep preparing final materials.

Mitchell’s Status Report for May 1

This week, I worked on more testing, final presentation, and video planning.  This Monday, we finished our testing, and found that our system passed all of our metrics. We started our video planning on Wednesday by drafting out our script and footage. On Friday I practiced the final presentation.

Since we are working on our final presentation materials, we are on schedule and our risks are simply losing our group members to second vaccine doses next week.

Cambrea’s Status Report for May 1

This week I finished all tests for the audio networking and made more formal output files with the results.   Our latency is~30ms and our dropped packet rate is ~.3% , both of these meet our requirements

latencyTestMic1

latencyTestMic2

droppedPacketTestMic1

droppedPacketTestMic2

We also finished the slides for our final presentation.

Today we are working on our final video outline and we are filming some clips of our meeting setup.

My progress is on schedule, next week we will be working more on the video and final report after our presentation

 

Team Status Report for May 1

This week we finished development and both started and ended our testing phase. Testing was conducted on Friday and Monday. This involved developing testing strategies, doing the tests while we were gathered in the same place, and then evaluating the results. We were happy to find that all tests passed based on our requirements!

We also finished preparing our final presentation, filling in the final test results and additionally including links to sample test data. Mitchell practiced giving the presentation to the group.

We started planning our final video this week as well. We outlined what we wanted to include in the video and drafted a script for the voiceover and the footage we want to capture.

At this point, since we’re focused on our final materials, our risks and scheduling constraints are passing into the rear view mirror. We’re on schedule with our work. Our main risk is that the second covid vaccine dose incapacitates two of our members who are getting it next week.

Mitchell’s Status Report for April 24

We performed our demo last Wednesday and received overall good feedback from Professor Sullivan and Abha. After the feedback, I implemented the capability to download the transcript as a pdf. It is implemented using reportlab using a file-like buffer to receive PDF data and the Paragraph model to input text. I also setup the basic testing interface template for the Server and Client Tests using getopt for Cambrea to use. For processes that require a sudo command, I used getpass to retrieve and encoded password, so the password is not stored in bashhistory nor in file and piping it into into stdio using the -S flag for the sudo command. I have also started working on the final report presentation slides.

Since we are performing our tests now, if there are any major issues that require an implementation overhaul, we would have to scramble to accomplish it.

This progress is on schedule. We plan to finish the transcript testing on Monday.

Next week I continue to work on the final presentation slides and the final report.

 

Cambrea’s Status Report for April 24

Last weekend we finished the migration to AWS so now we are running our server code on the ec2 server, instead of running our server on the local computer.

Since we are now running our system on the server we started on our final standard tests.  I completed the 2 tests for the audio device to aws server networking  this week .

I first wrote the latency test, this test sends packets to the server and should receive the packet back.  I capture the timestamp of the packet when it is sent and compare this to the time stamp of when the packet is received back at the raspberry pi to make sure we use the same clock to calculate the latency.  After sending 500 and receiving 500 packets we calculate the average latency of the systems round trip time.   We are getting the results of 27-80 ms average latency which is below our requirement of 150 ms latency.

The second test is the dropped packet test, this sends packets to the server for a fixed amount of time and counts the number of packets received back from the server, we calculate the dropped packet rate as (number packets sent – number packets received)/ number packets sent.  We ran this test for 2 minutes and 10 minutes and found the dropped packet rate to be less than 1% at .2% and .1% .  This also meets our requirement of <5% dropped packets in our system.

These 2 tests are in this ClientTest.py, this file works with the arguments

-b  for basic connection to the server test, send and received 1 packet to make  sure the connection exists

-l  run the full latency test

-d run the full dropped packet test

the tests are in the corresponding functions testLatency and testDroppedPacket

ClientTest

This progress is on schedule we will be testing until next week as well.

Next week I will be working on the final presentation slides and the final report.

 

Team Report for April 24

We performed our demo last Wednesday and received overall good feedback from Professor Sullivan and Abha. We had some technical difficulties during the beginning of the demo, so we started to add some robustness to the routines. The issue occurred when there were two microphones connected to a meeting and one of the microphones was disconnected. We also worked on testing the AWS deployment as well as formalizing the testing scripts. We also added in the ability to download transcripts of the meeting as pdfs. We have also started working on our final presentation slides.

Since we are performing our tests now, if there are any major issues that require an implementation overhaul, we would have to scramble to accomplish it.

Below is an image of our contraption. It has a Raspberry Pi, microphone, ReSpeaker, and custom ReSpeaker case.

Below is an image of our meeting transcript of our meeting in progress.

Ellen’s Status Report for April 24

We’ve made a lot of progress the last two weeks. Our demo last Wednesday went well, and afterwards because of the feedback we received we decided to revamp the speaker id setup process to make it more user-understandable. I worked on doing that all weekend, and then we tested it a bit on Monday while testing the AWS deployment.

Then Tuesday and Thursday I worked on outlining and fleshing out our final presentation slides. I also came up with a potential method for transcript latency testing.

Since we’ve already moved on to validating requirements (with a high confidence that they’ll pass)  I’d say we’re on schedule according to our Gantt chart. This week we’ll finish gathering and evaluating test data. I’ll probably be calculating a lot of transcript related error rates. We’ll also prepare our final presentation and work on our video.

Updated Gantt Chart

Updated Gantt Chart Link

For our updated gantt chart, we have completed the task “Integration of RPi + Transcript + ML” half a week early so we are currently working on the task “Complete System Debugging / Testing”.  Our current “complete system” for the demo uses a computer as the intermediary server that handles the speaker ML and transcript streaming.  Ellen is working on some ML improvements for integration and testing at this time. After the demo Cambrea and Mitchell will start the migration to using the AWS Server instead of our local computer for the task “AWS Migration”.   For our latency testing and  standard testing we will complete these during week 12 and 13  after we have migrated to AWS.  We will start revising our final report the during week 11, and work on our final presentation and video during weeks 12-14.

Cambrea’s Status Report for April 10

Last week week I completed the streaming code and AWS server code that is responsible for sending and receiving  audio over the network,.  The ReSpeaker offers a capability of detecting whether a user is speaking, using the is_voice() parameter.   I was testing this capability over the last weekend and found that the output audio using this information is too choppy to be intelligible to the user.   We are currently testing if after we tag the packets as voice and feed those to the transcript, if these packets have enough data to create the transcript.

This week we started integration of each of the systems so we were working on campus in HH D level.  On Monday and Tuesday I added the raspberry pi’s to the cmu device wifi.  We were having issues with connecting the devices to the wifi so we reflashed the OS to the SD cards on the raspberry pi and reconfigured the wifi and it now works on the cmu-device wifi.

On Wednesday we finished the integration between the audio streaming on the audio devices and the transcript generation on the server.  For this integration we are currently using Ellens computer to act as the Server so that we can complete the integration for the demo before migrating to using the AWS Server.  We are currently developing the speaker Identification more to make sure that I works to recognize different speakers.

This week we will start the tests for transcript accuracy, prepare for the demo, and also start the migration to AWS.