Weekly Status Report

Mike’s Status Report for 2/24/24

This I worked on implementing the front end prototype for 4 hours. First, I spent some time getting the Raspberry Pi to connect to the internet. I’m sure exactly what the issue was but I reset the OS and it started connecting properly. After that, I started implementing the UI in React. I have making components based on the figma, and I have been making small changes here and there to make the UI a little more user friendly. I have spent a bit of time trying to get communication  between the front end and the backend, using a JSON format API similar to the one that we showed in the presentation. But all in all, I spent most of my efforts getting the front end to start looking like the figma.

I spent 4 hours watching design presentations in class this week, and it was cool to see how everyone’s projects are going. As for the schedule, I am currently on track, as right now I am designing the front end and back end which just started on the Gantt chart. So for this next week, I will continue to keep designing the front end and back end.

Team Status Report 02/17

We anticipate lots of iterations to our initial design as we move on to the implementation phase. The vertical and radial aiming system might encounter issues with lack of torque that prevents the mechanical parts, which will force us to use a different design that uses gears to increase the torque output (or order another motor with a greater torque). The pressure system poses a mechanical challenge of reliably holding the pressure without leaks. The frontend design could be unintuitive to the new user once we start user testing. All of these risks could throw us off schedule. We plan on tackling these challenges by staying ahead of schedule and designing contingency designs with different tradeoffs in case the first design doesn’t work as intended.

 

There were two major changes to the design this week: The vertical aiming system will no longer use a linear actuator, but use a servo motor. We made this decision based on the feedback from the meeting with the professor, as it eliminates lots of noise and complexity when a triangulation-based design is used – the cost of the motor is a lot cheaper as well. The CV portion was changed to use a more low granularity LIDAR camera as the other group that planned on using that camera has returned the equipment. Both of these changes improve our designs’ robustness, and reduce the cost.

 

There are no schedule changes as we’re still ahead of schedule. We are working hard on individual subsystems while preparing for our design presentation next week.

 

Part A was written by Alex:

PongPal plays a crucial role in addressing public health concerns, specifically in preventing the spread of viruses like coronavirus. By allowing players to engage in water pong remotely through a web-based interface, PongPal minimizes physical contact and the need for individuals to be in close proximity during gameplay. This adheres to health and safety guidelines from the CDC while also  reducing the risk of virus transmission. Moreover, the remote play option opens up new possibilities for individuals with disabilities who may face challenges in participating in physical activities. PongPal is an inclusive platform, promoting mental health and well-being by providing an enjoyable and accessible gaming experience for a broader range of users.

 

Part B was written by Mike:

PongPal was designed with social interaction in mind. Many social groups form around a shared love for water pong, therefore allowing the game to be more inclusive can help those who could not normally play the game socially interact with water pong enthusiasts. PongPal’s remote aspect can also allow for competition thousands of miles away, allowing for an increased web of social interaction, thus growing the water pong enthusiast community. By considering social, cultural, and political dimensions, PongPal enhances the overall social experience, fostering a sense of camaraderie among players and contributing positively to the social fabric surrounding the game.

 

Part C was written by Simon:

PongPal’s economic factors are addressed through its accessibility and affordability. The product utilizes existing technology, making it cost-effective and reducing the economic barrier to entry. The system of production and distribution can be streamlined if mass produced, ensuring efficient availability of the robot and its accompanying web platform.

Mike’s Status Report for 2/17/24

This week I worked on the front end and its API for 4 hours. I spent a few hours finishing the design the UI using figma, as well beginning to implement it in react. I designed the API, choosing to JSON to send information between the front end and the RPi. The RPi will be using express, which runs on node js, to be doing light back end work receiving and processing the JSON requests from the user. The front end and the RPi will make a link of connection by using Duck DNS in order to account for IP address changes. The frontend will simply send information about how the cannon should be positioned and if the user fired the ball in a JSON header, and the RPi will respond with the location of the shot and if it made a cup, also in a JSON header. Later in the week I picked up the raspberry pi and configured it. Once it was set up, I spent around an hour setting up the internet on the raspberry pi, as I was running into issues with CMU device. Alex helped me and we were able to connect to the internet, but not websites. We are still working on a solution.

I also worked on the design presentation for 4 hours this week. I mainly focused on the slides API and frontend, but I also helped around with all the slides in the presentation. As for the Gantt chart, none of the frontend aspects are in supposed to be in progress yet, so I am ahead of the schedule. Next week I plan on getting internet connection and set preliminary connection between the RPi and the frontend.

Alex’s Status Report 02/17

Time breakdown for this week:

  1. Class (4 hours)
  2. Design (4 hours)
  3. Setup RPI (2 hours)
  4. Tinker with camera (3 hours)

This week I worked in class on the design for 4 hours, I mainly finalized the design for the pressure subsystem. The main ideas all stayed the same (i.e. we have an electronically controlled proportional valve to decrease the pressure, an air pump to increase the pressure, and a release valve to fire the ping pong ball.

Additionally, I was working to see if we could use an Intel Realsense Depth Camera D455 instead of an Intel Realsense LIDAR Camera L515 as the one that 18500 has was being used by group B1. This did not work, but luckily for us group B1 didn’t end up using the L515, so we can use it now. That unfortunately means that what I was working on with the D455 is not useful anymore, but that is good because I didn’t really feel like we could ultimately get anywhere with it given its lighting requirements.

This week Mike and I also worked on setting up the Raspberry Pi, it was harder than I remember, but it wasn’t too bad. Mike and I were having a lot of trouble getting the internet to work properly. We got the RPi to connect to the internet, but for some reason we couldn’t connect to websites.

We plan on ordering some parts this coming week so I can work on the pressure subsystem. This week I also plan on using the L515 when I receive it and I hope to get some progress on that.

As of right now we are ahead of schedule as I have already tinkered with a camera and stereo range detector to see how well they work for our use case.

Seung Yun’s Status Report for 2/17

This week, I finalized prototyping the vertical and radial aiming system in SolidWorks. Attached are the rendered images of the prototype.

In addition to prototyping, I’ve placed the order for the motors needed for each system. For the radial aiming, we’re using this motor, and for the vertical aiming, we’re using this servo motor. Both motors were selected based on high torque it provides. The radial aiming system is the same as the design that we originally had, but the vertical aiming was completely redesigned after our meeting with Prof. Fedder – the design that uses servo aligns with our design goals or precise angular control more closely, while also achieving it at a much lower cost (the linear actuator with long range was around $100, while this servo motor is only $15).

Moreover, I will be presenting for our team for next week’s design presentation, so I’ve been working on absorbing the design details of the other subsystems of our project, and have been practicing my presentation as well.

I am still on schedule. The goal was to finish prototyping this week and start construction of both systems next week, so once all the parts are delivered, I will start laser cutting individual parts and assembling them to see if they work as intended.

For next week, I plan on constructing at least one of the subsystem’s prototype and see if they work as intended. If it doesn’t I will have to iterate on different design.

Team Status Report for 2/10

This week, we presented our Proposal Presentation to the class and received feedback. The overall feedback was positive, with constructive criticism to be addressed, such as the camera pole impacting the portability, and having different testing environments to make our CV algorithm more robust.

After the presentations, we focused on drilling down on the initial design as we prepare for the Design Presentation. For example, we started asking questions such as “what is the minimum torque that we need for the stepper motor?”, “How many frames of images can we capture in the ball’s trajectory, and is that enough to assess where the ball will land?” As we start to consider these questions, we are starting to have a specific technical requirements for the parts we will order.

We are also approaching individual subsystems with an iterative improvement in mind. For example, Mike will be focusing on making the website and communication protocol functioning first before jumping into Figma. Alex is starting with assumptions such as “no other objects moving except for the ball” to hone in the ball trajectory calculation algorithm first, then slowly remove the assumptions to perfect the ball landing detection. Seung Yun is considering the pros and cons of fish-line design and linear actuator design for the vertical aiming, and how quickly we can go from one design to the other in case the first one doesn’t pan out.

Alex Status Report 2/10

Time breakdown for this week:

  1. Mandatory in class time (4h)
  2. Design Slides (4h)
  3. Basic Ball Detection (4h)

This week I worked on design slides for a couple hours with my group on Saturday. We started working on finalizing all the designs and we began making some of the slides for the design review.

On Friday night, I worked on doing basic ball detection. I have a couple videos that I could upload, but wordpress says “Sorry, this file type is not permitted for security reasons.” I found that the ball detection is fairly difficult to do on its own (even when I am assuming that the ball will be the only thing moving in the frame) and have decided to get a LIDAR+Camera to help with this. The LIDAR+Camera combination will allow us to get a depthmap that the camera can use and should greatly simplify the detection code while making it simple to estimate the ball position.

Michael’s Status Report for 2/10/24

This week my goal was to layout the groundwork for the website we will be hosting for to control our machine. I  have been working on the design presentation on today. We spent 4 hours working on the design slides. Earlier this week I practiced presenting for 1 hour, as I presented our proposal.  I went to the presentations on Monday and Wednesday and got to see a lot of cool projects.

I also spent 4 hours working on the website this week. For laying out the groundwork, I started by setting up a react project. I had worked with react a bit in the past, but I’m still relearning a lot of the ins and outs of creating websites. Eventually I created a baseline project with core UI components and a basic CSS sheet for styling. Besides setting up the website, I have been researching how to dynamic DNS connections for when we get the raspberry pi next week. Given that the IP we are using is dynamic and going to change, I’ve decided to use DDNS as a workaround.  I have found softwares that can connect to DDNS, like ddclient software. This software can update the DNS of the raspberry pi when the IP of the network changes so it can maintain connection to the site.

 

Seung Yun’s Status Report for 2/10

This week, I focused on prototyping the vertical aiming system and the radial aiming system. The feedback we got from the proposal presentation didn’t have major concerns with the mechanical portion of the design, so I started designing on Solidworks. We plan to build the robot’s scaffold to be laser cut from a 3/16″ thickness hardboard.

During the design, I’ve noticed that I would need the dimensions of the motors as a baseline, so I’ve also done some research on the parts we will use. For the radial aiming system, we’d need a stepper motor. The parameters that’s relevant for the purpose of radial aiming is low step angle for precise control, and high torque as lots of weight will be on the lazy susan base. The price has to be reasonable, and the speed of the motor is not relevant for our purpose. We came across this motor that meets the requirements, so we plan on placing the order for this part soon.

The the vertical aiming, we are still debating between using a linear actuator or using another stepper motor and using a string to coil to control the PVC pipe. We plan on fleshing out this design sometime next week as we prepare for the design proposal presentation, and order the necessary parts.

We are ahead of the schedule according to the Gantt chart, and by next week I plan to have a fully fleshed-out Solidworks design and have all the necessary parts ordered.