Category: Team’s Weekly Reports

This week, all the team members worked together to complete the overall system test with 3 instructors and test the performance of the system a few more times with different speeds to figure out the speed that’s most stable to be used during the final demo. Since we have completed all the design and build of our system, the most significant risk at the current stage would be unexpected damage to the physical components. Therefore, we would be particularly careful during the testing and ensure the motor is not overheated and the current and voltage supplied would not exceed the corresponding value on the data sheets that damage our motor driver or motor.
There has been no change made to the design of our system during the past week.

The unit tests we have carried out include latency tests for both erasing and image capturing, the user test of the website, and the power consumption test. In addition to that, we have completed the overall system test with 3 instructors and 3 students. From the latency test, we found the time taken for erasing a 30’’x 15’’ area of board takes 50s and the captured image should be displayed in 1.3s. From the power consumption test, we found that the peak power of our entire system is 50.65W. From the user test of the website, we have identified several confusing elements and the lack of instructions on the website, so we have modified the nav bar as well as added different instructions for both students and instructors on their home pages. From the overall system test, we have received feedback that the latency of the erasing board is a bit too large. For this reason, we are still exploring the peak speed our system can achieve while ensuring its stability. Other than that, we have also received feedback from Prof. Yu and Prof. Mukherjee that there are some glares in the images, so we will also find an optimized location to place the camera by adjusting its relative height to the board to avoid this issue.

1. Currently, we do not expect that there exists any risk that could significantly jeopardize the project with high probability. However, we do acknolwedge that our system doesn’t yet have a protection on motor driver to ensure it doesn’t burn under high voltage. The way we manage the risk right now is to provide moderate amount of power so that the system works properly without approaching the voltage and current limit of the motor driver. Next week, we plan to explore into whether we could add more robust protection so that the project is less likely to function incorrectly due to such a reason. Specifically, we plan to look into adding fuse suggested by our TA.
2. No significant changes are made to the system as we’re approaching the end of semester and would like to keep our working version of the system. We do plan to demo the project locally since there isn’t much difference for demo’ing purpose whether or not we deploy the project and we would like to save some budget on that. In addition, we updated our use case requirements on power consumption and erasing latency according to our new use case when we work on the final presentation. But they are slight changes and don’t affect how the system work.
3. Schedule doesn’t change.
4. 

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.

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.

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.

The most significant risk we have currently is about the mechanical design of the erasing system. After discussing with professors, we realized that the friction between the side of the rails and the wheels might prevent the wheels from moving. We will address this risk by adjusting the pressure applied on erasers, which is causing the friction between rails and wheels. We also identified some back up plans, in case the original design would not work. One is to make the wheels rotate vertically to the board, but this design might also face the issue of friction caused by gravity. Another more promising back up plan is to use a screw rod with non-captive stepper motors, but the shipping time of the components is long.

We made several changes to our current design. First is that we decided to remove the solenoid from our design, as a trade-off between functionality and stability. We think that erasing only part of the board, which is what solenoids are for,  does not add too much to use case. On the other hand, solenoids add much risks and vulnerability to our physical design, because of the sudden push or pull force it exerts on the whole system. Second is that we decided to modify the eraser moving mechanism as described in the last paragraph. We now have 3 plans, and we will test each plan to see which one works best.

In response to those changes, we modified our schedule. First, the solenoid task is removed. Second, due to shipping delays, we postponed the task of building the mechanical system. We are unsure of when things will actually be delivered, but we will be working on other available parts of the project, while waiting for things to arrive.

In the past two weeks, our team spent most of our time adjusting our design and writing our design report. After further discussing the use case with Professor Yu, we have decided to shift our objective to build a “virtual board” that provides unlimited board space and decided to include the camera and projector in our project so students and instructors can access pictures of content after erasing it, and instructors can project the erased content back to the board.

In addition, after discussing our design with Professor Mukherjee, we realized that the hex-shaft wheels we chose would not work well with our D-shaft stepper motors, and we needed to include motor drivers and mounting hubs in our design. Moreover, we needed to reconsider the options of slider rails that will be incorporated into our design, since it might be hard to 3D print the slider rails with a length longer than 12 inches. Therefore, we spent a lot of time investigating parts with dimensions that match with each other and meet our requirements, and came up with a new list of materials. With those updated details, we have created our new design diagram and updated block diagram, placed orders for the new parts we found, and adjusted our schedule accordingly.

Since we have made a lot of changes during the past two weeks, our schedule has become slightly more packed with more additional tasks about the new features than we originally planned, which might slow down our progress in the future. The team members have decided to invest extra time during the next few weeks to set up the physical attachment and catch up with the progress to mitigate the cost.

For now, the most significant risk we identified that could jeopardize the success is we are still not sure whether our slider rail choice would fit well with the rest of the parts given that even thought the dimension matches, we need to ensure it’s strong enough to hold the other components. We planned to check out the struts at Tech Spark, but found that Tech Spark is closed during the fall break. We have also discussed the available options online but found out that the U-shaped channels that match the width of the wheels are either too high or too long for our design. We have decided to go with an aluminum U-channel that is longer than the dimension of our board and manually cut it at Tech Spark. To mitigate the risk, we have selected a few other channels that are slightly wider than we expect as backup options, and decided to place the order and pick them up as soon as possible at Home Depot if our original plan fails.

This week, our team has spent a great amount of time working on finalizing the details for our first components ordering. While we worked on this, we realized some potential risks that could be more dangerous to our deliverables. This includes mostly the assembly of the physical board + eraser + wheel + rail + RPi. We need to ensure that the following aspects don’t fail:

• the power source should have enough voltage to support the motor, linear actuator, and RPi.
• the components aren’t too heavy to make the board not balanced.
• the communication between PRi and our web server should be generalized, and this part is the one that we haven’t addressed enough in our meeting this week and we decide to worry about the hardware parts for now and invest more time on RPi and web server integration after fall break based on our schedule.

For the first two components, we’ve searched for potential physical components that could give enough voltage while has a light weight. And we’ve successfully found the components and added it to our budget list. However, the rail we decided to spend some time exploring the 3D printing options as there isn’t a rail online that fits well to the wheel we found. Besides this, we currently don’t have major changes in our system spec. Due to the change, there is a slight decrease in our cost, but we will still need to check if we need to spend any money on the 3D printing.

Since the change is in system spec instead of how we design the process, there is no update on the schedule. Below is our current budget form.

To answer this week’s question, we’ve applied the following principles of engineering, science, and mathematics:

• during the solution formulation, we prioritized the approach that gives the most general capability while being of great familiarity to most group members. Therefore, we’ve utilized our knowledge in software engineering so that we could use the Django framework to manage the backend of our web app with access to relational DB that stores relevant information about the student’s “voting” mechanism in our project.
• We’ve also considered various types of motors and control systems with our background in embedded system engineering and decided to use stepper motors to have better control over the precision of movement.
• We also applied our knowledge in electrical engineering to come up with potential solutions to wire the components together so that we could reduce the cost of power sources by buying fewer batteries while supplying the voltage to more components.

This week the biggest challenge and risk we faced is reconsidering our use case for the project. Previously our use case consideration are very wide and not in depth, so we really struggled coming up with quantified requirements and tests. We are managing this risk by having discussions with professors and refining our use case before the design presentation.

The major design of our project does not change much. However, we are planning to rephrase our use case to make it more clear, as feedbacks have shown that our use case is somewhat confusing.

About schedule changes, Jiayi and Wenqi are planning to postpone setting up frontend and backend of the web app to next week, because they are out of town this week.

Currently, the most significant challenge we expect is building our system on the whiteboard. We are worried that the parts we bought might not fit well with each other. We are also concerned that the system might not work as we expected in physical aspects. To solve this problem, we are actively looking for different variations of parts to use as backup plans.

After discussion with the professor and our TA, we decided to keep our design of the system as the feedback indicated to us the current proposal mostly meets the use case requirements. However, we did spend some more time creating a detailed sheet on the budget of our important components. 

Our schedule currently remains the same as specified in the proposal. Further changes might be made after we meet with our professor and TA next week.

Our project involves the importance of public welfare. More specifically, we should consider the educational factor because the primary goal of our project is to help the professors and students with erasing boards and notetaking during lectures. Therefore, we will need to consider their needs more thoroughly while designing the functionalities, so our project can contribute more in the aspects of education and public welfare.