Posted on

Alejandro’s Status Report for 4/12

This week I mainly focused on getting the path sequencing to work with the motors. I changed the code in Arduino to run on a switch case statement control flow with four main states. There are some bugs with this as when the motors are told to move to a specific trash bin coordinate they move to the origin, which is wrong. Additionally, I implemented the button and the speed control frontend and backend on the web app portion of our system. Now I just need to ensure that the Arduino can take the data relayed from the Jetson and execute it correctly. I also got the web app to receive the bounding box coordinates from the Jetson.

As for the verification of the measurements, I intend to schedule the pick up and drop sequence without suction. My analysis will be based on a scale of time. If the gantry is able to reach a location within 15 seconds and complete the entire execution of pickup and drop off within that time (excluding the suction) then I know that the path sequencing component works as per the design requirements on my end. Additionally, I will test the latency of the web app video feed by running a timestamp on the jetson when it sends data to my server and then timestamp the receipt of it on the server. Then I will perform the analysis by taking the difference of the two times to see if the latency meets the use case requirement.

My plans for the future are to fix the path sequencing code and finalize the canvas drawing on the front end of the web app. I also plan on coding the controls for the conveyor belt. I also need to ensure that the Arduino receives the commands from the Jetson’s relay of commands from the web app interface.

I am currently on schedule.

Posted on

Alejandro’s Status Report for 3/29

I spent the majority of the week figuring out how to increase the speed on the motors controlled by the Arduino and fixed the vibration issue that would occur with them. The movement produced by the gantry system in the xy plane involved a considerable amount of vibration and slow movement. In order to fix this, I had to modify the C++ code for the Arduino so that the commands sent to the motors were more frequent to keep the motors from stopping at each step that they would execute in terms of their movement (they’re stepper motors). Additionally, I started implementing the code to control the Z axis, in this case the end effector motor. We don’t have a third cable to control the motor so I have to wait for it to arrive in order to verify that it works in conjunction with the other two motors of the gantry system.

My progress is currently on schedule.

For next week, I plan on finishing the code to execute a complete pick up and drop sequence for specific trash types. I also plan on programming the conveyor belt to move once built.  

Posted on

Team Status Report for 3/22

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk to our project is getting the machine learning model to run at a speed that’s close enough to real-time speed.  To do this we plan on making sure that we make a thorough analysis of the speed and accuracy tradeoffs until we reach the most optimal point of performance in the balance between the two. On another note, I next greatest risk is the failure of the gantry system to move fast enough to handle various objects moving along the conveyor belt. A contingency plan is that we’ll have a speed control feature on the web app to slow down the speed in the case that there are too many objects being passed through the conveyor belt for sorting. This would allow our robot to have enough time to sort all of the items being passed through without having to skip any.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

There are no current changes made to the existing design of the system.

Provide an updated schedule if changes have occurred.

There are no schedule changes as of now.

Posted on

Alejandro’s Status Report for 3/22

I spent the majority of the week programming the Arduino to control the stepper motors to move the gantry’s xy movement. I spent a significant amount of time figuring out how to move each stepper motor to yield a specific spot on the xy coordinate plane. I can now calculate a specific location on the xy plane and move the location where the end effector is to be placed to that specific location. The C++ code is written inside an Arduino file that controls all of the movement and stepper motors. Additionally, I fixed the issue with the web app streaming by moving the server to run on Powershell so that there are no port confusion or firewall issues when running it from WSL on my Windows machine.

My progress is currently on schedule.

For next week, I plan on writing the code to translate the coordinates given from the Jetson to the values needed for the motors of the gantry due to its unique pulley configuration. Additionally, I’ll work on controlling the end effector once it’s physically been added to the system.

Posted on

Alejandro’s Status Report for 3/15

I spent the majority of this week working on reconnecting the Jetson to the webserver, since it no longer connects to my WSL server.js instance. I spent a considerable amount of time trying out different ports and connection methods. The first method I tried was to try and reset the firewall privileges on my laptop, but that failed to work. I then moved onto attempting to change the port forwarding on my device to the WSL port, but that also failed to work properly. The Jetson pings to my laptop but no longer wants to connect to the server. If I am unable to get the websocket working again as I had it before, we may have to shift to a tethered wired connection for the time being. Additionally, the canvas drawing feature is implemented. Also, the gantry xy axis is fully assembled now.

In lieu of this obstacle, I will plan to try one more time to get the websocket connection to work, and if it fails I will shift to using a wired connection. Additionally, I will test the canvas drawing with some test values next week as well.

I am currently on schedule aside from the minor hiccup.

 

Posted on

Team Status Report 3/8

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk to our project is that the suction-based end effector won’t be able to pick up different types of trash items. We’re managing this risk by focusing a considerable amount of time on the development of the end effector mechanism. In the case that the suction with the vacuum pump is ineffective, we plan to pivot to a claw like end effector mechanism for picking up the pieces of trash.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

There are no current changes made to the existing design of the system.

Provide an updated schedule if changes have occurred.

There are no schedule changes as of now.

Part A was written by Teddy, Part B was written by Ethan, and Part C was written by Alejandro.

Part A:
with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

Currently, the issue of proper waste processing is one that many countries, including the US, are struggling with. Many countries do not have the infrastructure to pay for recycling facilities, as it requires a lot of manpower, and the resulting materials are not very profitable. Additionally, a lot of our waste is shipped to other countries in order to prevent it from piling up here, however this means that other countries are burdened with our trash. SortBot could help reduce the amount of trash by separating out the useful materials, at a much lower cost compared human workers. This could potentially help other countries without the funds for recycling management to do so.

Part B:

In the United States, the common practice is to dispose of all types of municipal solid waste in single bin, prioritizing convenience over environmental concern. SortBot is set out to challenge this norm, one that focuses on ease and efficiency, by introducing an autonomous system that streamlines waste separation without requiring a behavioral change. By shifting the responsibility of sorting waste away from the person throwing away the trash, SortBot can work within the existing American cultural norms. This ensures that materials can be property sorted without requiring individuals to change their habits. While this is not the best solution for this issue, it is one of the most appropriate for current American culture.

Part C:

Our product solution will meet the need of the consideration of environmental factors by providing a streamlined method to making the environment cleaner. Utilizing advanced computer vision and machine learning algorithms, our robot has the ability to identify and differentiate between different types of trash and can thus correctly categorize the trash types and sort them into their respective bins. The system can aid in the sorting of trash to aid in the recycling of these items. Normally, all recycling items mixed with trash would normally end up in landfills and be lost in terms of the value that they could provide when recycled, but now with our product solution, we can recover these items and help in reducing the environmental strain of waste disposal.

Posted on

Alejandro’s Status Report for 3/1

I spent the majority of the week working on the assembly of the x-y axis of the gantry system. The assembly was time-consuming and laborious. The assembly requires a few more steps that will take some considerable amount of time. I will work on finishing the assembly the week I get back from Spring break. My progress is slightly behind schedule. In this case, I will prioritize the assembly of the gantry’s xy axis in the following week of work. Additionally, I was experimenting with the use of the canvas drawing onto the camera feed but I will need more time to solidify the feature. I’m also running a bit behind with the canvas drawing feature but I’ll have that done promptly after assembling the gantry. So next week I intend on completing the gantry xy axis and finishing the implementation of the bounding box HTML feature of mine.

Posted on

Alejandro’s Status Report for 2/22

I successfully established the WebSocket connection between the Jetson Orin Nano and my laptop’s localhost server. I then configured my server.js to stream the video served over the WebSocket connection to my web app. Additionally, I had to change the index.html code to properly display the video being streamed. After several hours debugging, I finally got the webapp to stream video. Now, the web app displays the video of the camera that’s connected to the Jetson Orin Nano. Here’s an image of the video feed of me being displayed on the webapp. 

I am currently slightly behind in that my team had planned to assemble the xy axis of the gantry system this week; however, my team ordered only two rods of 3 ft when we expected two rods of 6ft each. The other two 3ft steel rods should arrive next week. In order to make up for this delay, I’ll take a day sometime next week to assemble the xy axis of the gantry system.

Next week, I need to also implement box shading onto the HTML of the webapp to display identified objects on the camera feed. And as previously stated, I will also assemble the gantry system. At the very least, I’ll assemble half of it in the case that the other two steel rods do not arrive in time.

Bytes Sent over Websocket Between Jetson and Server

 

 

Posted on

Alejandro’s Status Report for 2/15

This week I spent time investigating web socket video streaming methods for a web app on a local host. I realized that Django would be too slow as it isn’t optimized for real-time streaming purposes as it is mainly meant for handling database/multi-user applications. Nonetheless, I decided to shift the framework to Node.js since it’ll provide lower latency in video streaming. I worked on writing the JavaScript file to set up the server backend. Additionally, I rewrote the index.html file to display counters of the types of trash collected, a camera feed box, and information on the types of trash rules we’ll be following. I also, reinstalled the OS on the Jetson so that my team and I would have access to it. I also setup RealVNC viewer so that I could use the Jetson without connecting it to a monitor. To make this work without RealVNC, we may need to order a Vesa cable.

I tried streaming an mp4 video but encountered some issues on the front end. I’m going to continue debugging this so as to be on track with the video streaming component of the web app for next week.

Additionally, I was supposed to assemble the XY axis of the gantry system this week but parts are taking longer than expected to arrive. Thus, I will continue as planned and take a day in the upcoming week to assemble the XY axis of the gantry system.

Posted on

Team Status Report 2/15

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk we could face right would be a poor design for the z-axis end effector. Currently, we are exploring (and have placed an order for) a couple of suction cup end effector and pressurized mechanisms to enable pick up and drop off. However, going forward, we need to be very careful as we are most likely going to depend on off-the-shelf components and the wait time to have these arrive is longer than we would like. In order to mitigate this risk we are going to place orders for these off-the-shelf parts if we have really thought hard about how these off-the-shelf components will integrated into the end effector. This way we can use our limited time more effectively. The main contingency plan would be to fail back on designing some of vacuum system to pick up and drop off items.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No major changes have been made yet.

Provide an updated schedule if changes have occurred. 

No schedule changes have been made.

 

Part A was written by Alejandro, Part B was written by Teddy, and Part C was written by Ethan.

Part A:

With respect to public safety, SortBot helps in reducing the risk that human sorters take when interacting with trash inside trash processing facilities. Our robot reduces the risks of workers being cut by the trash they’re sorting and being exposed to harmful chemicals that could shorten their lives and livelihoods. Additionally, the reduction of manual labor the workers will have to do would also decrease the risk of musculoskeletal related injuries. On the aspect of welfare, our robot would allow workers to move from doing monotonous skilled labor to being more specialized workers. They would be exposed to less hazardous roles and would have more opportunities to advance their skill sets leading to career growth. Finally, our robot would improve the recycling rates of trash sorting facilities which would allow for a less polluted planet.

Part B:

With respect to social factors, SortBot would be able to help establish recycling in countries not just within, but outside the US. Currently, due to the costly and labor-intensive nature of recycling, many economically weaker countries do not have the infrastructure to implement recycling. However, SortBot will be able to reduce costs associated with recycling, making recycling feasible in the countries which cannot currently afford it.

Part C:

With consideration of economic factors, SortBot is made solely from off-the-shelf components that can easily be assembled together without requiring additional fancy tools or machinery. Most of the complexity of SortBot comes from the custom software in each module, however, this can easily be replicated or made entirely open sourced for people to use. There should be no difficulty in setting up a system to mass produce many SortBots as nothing “weird” is done during its assembly. SortBot is also easily to be distributed to waste management facilitates as none of SortBot’s components require any additional handling and operate for a long time before breakdown. SortBot simply needs a wall outlet. This plug-and-play nature was one of our major design goals with SortBot, both in price and easy installation (needing multiple additions to aid the integration of sort would be expensive).