Posted on

Team’s Status Report for 11/18

The most important risk we have now is the stability of the physical system. Now that our team have completed most of hardware and software components of the project, we are now left with the mechanical part, of which all of us are inexperienced. We are planning to integrate all parts together using wood pieces. To mitigate risk, we plan to ask for help from staff at Techspark for cutting the wood, as well as reaching out to MechE friends for advices.

We are considering making changes to our design or latency requirements. Before, we were hoping that a new motor would boost the speed of erasers by 4 times, but the motor we receive does not meet the specifications of its data sheet, therefore it cannot be used. We are reaching out to the vendor about this issue. If things does not work out, we are considering relaxing latency requirements of the system and using the slower model we had.

Here is a photo of the mechanical system we have built so far. 

In response to weekly question, our team has collaborated effectively throughout the semester. We know each other before this class, and decided to take 18500 together as a team. Thus, since we know each other well, we are able to communicate effectively. The main strategy for our collaborations is to discuss problems and assign tasks clearly during our meetings, then work on our assigned tasks individually.  We make it clear what each person is responsible for and when each person is available, so that everybody has a clear picture of what’s going on. Overall we are all proud of what we’ve accomplished as a team.

Posted on

Wendy’s Status Report for 11/18

This week, our team started to build the mechanical part of our system. Currently, we finished the basic skeleton of the system to hold the board and upper linear slides. However, due to the fact that the NEMA 23 motor we received doesn’t match its specification, we could not fit the NEMA 23 motor in our system unfortunately. Therefore, we will start with incorporating the NEMA 17 motor we used before this Sunday and wait for any reply from the supplier.

Individually, I spent the majority of my time working on refining the user interface of the web application and adding functionalities to enhance the user experience. I have updated the CSS of our web application incorporated some responsive design and implemented the home and logout functionalities and button as the content of a dropdown box located at the navigation bar. Moreover, for the create/modify class form page, I have changed the integer field of width to a choice field for users to select which preconfigured board the class will use since this is more intuitive for users (and typically the instructors will not use their own board while lecturing), and I changed the clean function of the form to validate whether the student IDs input by instructors are valid and raise a form validation error if one of them is not.


Regarding testing, since I’m responsible for the camera, I have completed the camera latency test by writing javascript to measure the time taken between a user clicking the “erasing board“ button and the picture getting posted to the website  5 times and taking an average. The time averages to 1.3s and meets the metric (3s) we set for the user case requirement.

I also finished the script for the usability testing of our website. Therefore, according to our schedule, my progress is on schedule. 

Next week, our group will finish building the mechanical attachment and start working on the final presentation and report together. I also plan to recruit some participants to participate in the usability testing of the web application and improve our website based on their feedback. If I have extra time, I will also spend some time investigating how to the web application with Canvas so instructors do not need to manually enter the student ID (which is a post-mvp goal).

Posted on

Jiayi’s Status Report for 11/11

This week, I spent some amount of time preparing for interim demos and making sure the logic of webapp works fine together with Wendy. At the same time, Xiaoyu’s code for RPi was ready, so I worked with her to conduct experiments on deciding the voltage, current limit, and speed of motor control. After making sure that our motor moves at expected, we meet again to discuss about building everything together using wood and screws. So we spent some time planning on the detail of how we will build the system and what items we need to purchase, and we made the purchase this week so we could get started soon early next week on building the physical parts together.

My progress is mostly on schedule, but this week we originally planned to build the physical components but weren’t able to do so because we’re still waiting for the materials. To catch up the schedule, we ordered some key components ourselves and will receive the material very soon to get started on building next week.

I plan to have the entire system put together next week (we’re missing communication between RPi and webapp + physical components). This could allow us to have sufficient amount of time on testing.

Weekly Question:

The tests we plan to run are: image capturing latency test. web application usability test, erasing functionality test, overall system test. The use case requirements include making functionality of capturing the image, providing user a web interface to access erased content, and erase the board automatically. We test these three aspects individually, and overall we test the entire system and perform user test to ensure we meet the use case requirements.

Posted on

Xiaoyu’s Status Report for 11/11

This week the motors arrived and I have successfully tested my  motor control code from last week. I also did current limiting on motor driver and now the motor can spin in both directions for different speed and distance. I also spend time writing accelerate function of motor, which allows it to gradually accelerate to a bigger maximum speed. Attached is a photo of the motor.

My progress is on schedule this week. Next week we plan to finish communication between RPI and website. Our team also ordered some wood, and are planning to assemble the physical component on the whiteboard next week.

For the motor part, I have already performed unit tests on functionality and latency. Currently, the motor is functional, but latency test performance is not satisfying, because the screw rod is very inefficient in transferring  rotation to horizontal movement. We ordered some new rods that are 4x more efficient, and will perform further latency tests later this week.

We are also planning to do some usability tests after we complete building and integrating the system. We will recruit participants and ask them to try out our website’s different functionalities, and ask for their feedback. We will also test latency in camera and projectors, as well as power requirement for RPI and motor.

Posted on

Team’s Status Report for 11/11

After we received the motor on the screw rod this week, we connected it to the motor driver and managed to use codes on RPi to control its speed and direction. However, one significant risk that could jeopardize the success of the project is that with the screw rod and the NEMA 17 motor we chose, the maximum speed of the motor moving is still too slow for board erasing. After researching the alternative screws online, we have found a screw rod with 4 times wider thresh and a NEMA 23 motor that could fit in the screw rod, which is supposed to move 4 times faster than the solution we currently have. Therefore, we placed an order for the new screw and motor to address this risk. We have also come up with a backup plan that uses motor-controlled strings connected to the two sides of the linear slide to move the linear slide in case the speed of NEMA 23 is still too slow.

Besides that, there is no other major change to our system. One minor change is to add several lumber blocks at the back of the board to support the board as well as the linear slide at the top of the board. This change is necessary to address the safety concern we have discussed during the ethics assignment. Therefore, we have placed orders for that lumber together with other wood sheets and will spend next Friday together to laser cut the wood plates and assemble the attachment.

Posted on

Wendy’s Status Report for 11/11

This week, our group worked together for most of the time to prepare for the interim demo, devise a detailed plan of how to connect our physical attachment to the board and place orders for the joint parts. Individually, I have also solved the problem of connecting the camera to campus WIFI, integrated the camera into our web application, and completed the OAuth login and registration functionality of the web application. Currently, I’m working on improving the user interface of the websites, which is my task for the next week. Therefore, my progress is currently on schedule. For next week, I will spend more time with my teammates on building the physical attachment and connecting the different subsystems together. I’ll also add back buttons and user log-out functionality to make the web application more user-friendly in the upcoming week and perform the latency test for the image-capturing feature.

Regarding the testing, we have planned to perform both unit tests as well as overall system test. We will test the latency of image capturing and erasing, and the usability of our web application as individual subsystems. Then, after we physically attach them to the board, we will also recruit participants to perform a usability test for the entire system. For the unit latency test, we will measure the time taken by erasing and image capturing, and compare the timing to the metrics we set to meet our user case requirement (20s for erasing the board we chose and 3s for image capturing and uploading to the web app) so it won’t impede instructors’ lecturing and students’ notetaking. For the web application usability test, we will recruit 3 users and test whether they can learn how to use the website without guidance and ask for their feedback on our websites. For the entire system usability test, we will recruit 6 users and ask questions about the cleanness of board erasing, resolution of images, latency, user experience, and accessibility of the whole system. To verify whether our project meets the use case requirements, user input would be essential. Therefore, we would analyze whether our system meets the requirement based on users’ feedback in the tests.

Posted on

Jiayi’s Status Report for 11/04

  1. Earlier this week, I spent some time with my teammates discussing about ehtics considerations in our product. And as our team starts on the major building process, I mostly worked on writing the code in backend, modifying views.py and models.py. In addition to this, I also helped Wendy on having the IP camera work by making sure it fetches and downloads the captured image.
  2. My progress is mostly on schedule, with some need to get started soon on investigating communication between webapp and RPi. I will spend more time after interim demo next week on the integration and webapp and RPi.
  3. Next week, I expect to spend some time on integration of webapp and RPi, and work on building the physical parts since we have most of our components ready (except for the motor at this moment).
Posted on

Team Status Report for 11/04

  1. After pivoting our design for the motor and eraser system, we expect a better performance for the screw motor because the movement mechanics is no longer significantly affected by the weight and friction exerted on the wheel. And as we start to work on the RPi and camera part, we notice some potential risks about the camera. It is an IP camera that can work under the same WIFI as the web app, and at current stage we are only able to obtain the JPEG format of the image captured through the camera by setting the camera and our laptop at the same WIFI (we have not deployed yet). Since we potentially won’t guarantee that things work the same once we deploy the web app, we see there’s some risk that could jeopardize the success of image capturing. To solve this issue, we investigated how the IP camera works and noticed the image is uploaded to the website provided by the company that sells the camera. We could look for potential APIs from the website or look into downloading the images from the website if our webapp cannot exist in the same WIFI environment with the camera.
  2. This week, we are working on writing code and exploring how to control camera and motor, etc. There is no major change in the design of the system. One change we are expecting would be that we want to add some protect around the screw rod and motor after our Ethics discussion because we feel the need to lower the safety concern as much as possible.
  3. Schedule change: we’ve moved camera to this week since it is part of the webapp backend code. Due to this change, we’re postponing the usability test for other webapp features.
Posted on

Wendy’s Status Report for 11/04

After finalizing our attachment design and completing the ethics assignment a week ago, our team spent the majority of time building our system in the past week. As Xiaoyu worked on the RPi code used in motor control, I and Jiayi continued working on the integration of the backend and frontend of our web application. Individually, I wrote the models.py, forms.py, and urls.py to help with the integration. In addition, I have spent a lot of time investigating the camera module, connecting it to the internet, and writing the code to control it and take a picture. Currently, I managed to complete the code that asks the camera to take a snapshot and store it in the local directory.

        

However, the current setting of the camera requires my computer to run the code to be connected to the camera’s WIFI hotspot or with a router through an ethernet port. I will still need to figure out how to connect the camera to a wireless network since this is required if we want to deploy our website and use the web application backend to communicate with RPi. Since the manual of the IP camera is a bit confusing in the wireless connection part, I have written an email to the technical support of the supplier of the camera and will continue investigating the solution to this problem.

Our original plan is to complete camera control functionality in the next week, but for the purpose of the interim demo, we have decided to complete it in advance so we can have more to demonstrate. Therefore, our progress is currently on schedule.

For next week, I hope to finish our web application, further polish its interface, and complete the usability testing of the website. Moreover, once receive the reply from the supplier, I will work on connecting the IP camera with the wireless network of CMU and finish the unit testing of the camera.

Posted on

Xiaoyu’s Status report for 11/4

This week I was working on controlling the stepper motor with Raspberry Pi. I spent quite some time learning to boot the RPi for the first time. I had some trouble with the micro SD card but managed to resolve that. After successfully boot the Rpi and access it through SSH, I also started testing my code written last week with some simple circuitry. I don’t have the power supply needed for the motor to spin, but I visualized the input and outputs to the motor driver with LEDs and they look fine now. Attached are pictures of the RPi.

Although last week my schedule was behind, this week I am gradually catching up. I still need to put in some effort in the next few days to make the motor spin, by connecting it to a power supply and (maybe) further debugging. Also, our non-captive stepper motor should be on the way, so our team can start assembling things on the whiteboard next week.