Category: Team Status Reports

As we approach the final demo next week, the only risk that remains is the parts failing. To mitigate this, we’ve made some spare parts that can be replaced on the fly. For example, we have multitude of motors for the pressure system, and we have replacement parts for all parts of the pressure system’s tubing. The aiming system also has a backup motor and motor drivers in case it fails.

We don’t have any major design changes this week.

We don’t have any schedule changes this week.

We’ve performed lots of unit tests and overall system tests recently. We’ve did individual unit tests for vertical and radial aiming system. The pressure system had reliability testing by shooting in the same setting multiple times. The vision system had accuracy testing by detecting the ball’s landing spot and cup’s true location. We performed user testing on our frontend. For the final integration testing, we’ve ensured that having the same setting yielded consistent landing location.

We were able to use the values from the testing for calibration. For example, the voltage reading from the pressure sensor was measured during testing to see what is the appropriate range for the game – we’ve found that 2V – 3V is the sweet spot, and have decided to use this range that users can actually set.

We haven’t made any significant design changes while testing, as the results passed our expected criteria.

We have lots of spare parts for the physical systems that mitigates most of the risk related to hardware failure. As we’re more or less done with individual subsystems, the problem could still arise as we’re integrating different subsystems. For example, the computational power difference between the Pi and the computer we’ve been testing the vision system on could lead to issues – we don’t anticipate this to be a problem, but worst case we do have a more powerful Pi (Pi5 that we didn’t end up using) so do these processing. Another problem that could be an issue is the motor shaking messing with the computer vision but we can avoid this issue through our software, to do so we simply don’t run any of the computer vision subsystem while the motor is running.

We have no major design changes this week.

We have no schedule changes this week. We will be focused on testing and integration for the rest of the semester.

The risk of the pressure system remains the biggest as of now. We’ve noticed the pressure is not leaving the tube as quickly as we hoped and making adjustments, but the new design might still encounter this issue – we are exploring mechanical shooting mechanisms to mitigate this risk. The hardware’s stability is also an issue. As we’ve experienced hardware failure on the microcontroller this week, having spare parts to mitigate this is going to be important.

We have no major design changes this week.

We’ve updated our Gantt chart this week to match the progress we’ve made. The cup detection and the pressure system has been moved back a little bit, and some of the workload has been re-distributed. The updated Gantt chart is attached below:

As we approach the last stretch, we have multiple verification and validation plans in place. For verification, as discussed in individual reports as well, the aiming subsystem will perform a series of movements and take physical measurements to verify it works.

For the validation, once all systems are built, we will test the system by launching the ball in the same setting 10 times to a grid paper, and note where it landed. As mentioned in design presentation previously, if we can draw a 2cm * 5cm bounding box on all the landing spots, we will have successfully validated our project.

For the computer vision ball detection validation, we will measure the accuracy by positioning the LIDAR sensor facing up. Then we will throwing a ball over the LIDAR sensor and record where it lands on the ground. We will then compare the actual landing location to where the LIDAR predicted. We will then measure the absolute magnitude of the difference between the two points. We currently plan on doing 50 trials.

For the computer vision cup validation we plan on setting up the cups and then moving the cups around and measuring the distance between where the cups are predicted to be and where they actually are, similar to the method used for ball detection. The main difference here will be that we need to map out in 3d space where the cups are relative to the LIDAR so it will be more of a pain to set up, but once we have our measuring set up and validated, we will be able to quickly collect data.

This week we’re making a strong push towards the interim demo next week. There are few risks that still remain. Since we haven’t gotten around testing the parts for the pressure system yet (we’ve been focusing on other components), there is a risk that it won’t be as stable as predicted. The strength of the stepper motor is rather powerful, so the stability of the base has come up as a new risk this week – we intend to have a heavy base and a strong mechanical connection between the motor house and the base to mitigate this. Other subsystems are nearing completion and we don’t anticipate any big risk, although their interactions may lead to some unexpected blockers.

We have made no major design changes this week.

We are modifying the schedule slightly to prioritize the finalization of the CV subsystem, so we’re bringing that closer to the current schedule. As Seung Yun is almost done with his part, he will start working on the pressure system together with Alex as it aligns closer to the mechanical parts he’s been working on.

The biggest risk we face as we approach the first integration of all subsystems is the reproducibility of the shots. As also mentioned during design presentation and during our meeting with professor this week, if there are not enough spin when the pingpong ball travels, it can essentially turn into a knuckle ball pitch, leading to unpredictable trajectory. While we don’t think this will be a huge issue as the travel time is short and there should be some spinning of the ball should already happen as it shoots out, we acknowledge that we don’t know for sure until we test it out. We aim to finish the first full integration soon so that we can adjust our design if it doesn’t pass our verification plans.

We don’t have any major design changes this week.

We don’t have any schedule changes this week as we had slack time integrated into our original Gantt chart.

This week our team members have worked on implementing the individual subsystems. As such, more possible risks are being discovered – in the mechanical system, especially in the vertical aiming side, the amount of torque that we initially thought that was enough may not be enough when attached to larger physical parts. More research into the materials that are lightweight, or redesigning the arm to be shorter may slow down our progress. In the vision system, the Pi’s processing power could potentially become a bottleneck at which point we might need something like Jetson Nano or send all the visual data to the cloud. The frontend might need some overhaul if the users find the UI un-intuitive. We will find out if these risks will actually hinder our progress as we work on these subsystems.

We have no major design changes, except a minor tinkering here and there. The radial aiming system will now include a stepper motor driver in between the motor and the Pi, and the UI is going through minor changes (such as color and layouts) to fit everything nicely.

Most of us are still on schedule and have not made any major schedule changes. Alex is ahead on ball/cup detection, but behind on the pressure subsystem as the parts are taking longer than expected to arrive.

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.

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.