Author: jameszho

This week’s main focus was the design review report. This was honestly more work than we anticipated, and we all had hoped to get more time to work on the separate components of our project, but we did a good job getting the report done while also continuing to get the ball rolling with our individual components. Writing out the report was also a great way for us to reflect on what we’ve done and flesh out all the details. It’s important to know exactly what we’ve done, what our goals, requirements, and responsibilities are, and what steps we need to take to get there. Working through the design doc was a great way to iron out all those important details, and we are all ready to resume work after fall break.

For Gordon’s KRIA updates, was able to successfully flash Ubuntu onto a MicroSD card, connect the KRIA system onto a monitor, and initialize the Ubuntu home page. Pictures are included in my own status report. There have not been many changes to the design, and after fall break I will be ready to try to run an example project that Varun has on his github guide, to get a good idea of how things run. Slightly behind schedule, but given everything going on both in this class and outside, it’s understandable and more importantly recoverable. More details listed in my personal post.

For the camera component, a design trade off was done between hough circles and YOLOv8 as outlined in the designed report, settling for the YOLOv8 model. Some preliminary implementations are also in the works for the Kalman Filter. A risk is regarding Kalman Filter – there is a possibility that the provided openCV modules may not be accurate / robust enough, and a in-house implementation is required. A contingency plan for this is to first get the OpenCV prototype working as soon as possible to understand the limitations of this approach.

On Josiah’s end, besides the design review report, construction of the robot is to begin following the end of fall break. Ordered materials will have arrived, and 3D printing of the housing will commence. The custom cup holder will be designed through a CAD software and printed as well.

Our production solution will meet these specific needs… 

Part A (Gordon): Our product focuses on the  very specific use case of training in the game of cup pong. Yet even though it is a super specific use case, it can be applied globally because of the international popularity of the game of cup pong. This is a party game that is not limited to just college students, as people of all ages all over the world will play cup pong at social gatherings. Our product helps the user without discrimination, as no matter who uses it, Splash will do the same thing: catch the thrown ping pong ball. Therefore, our product will satisfy the cup pong training needs of cup pong players globally.

Part B (Jimmy): Our product has a very relevant cultural aspect in aiding players who want to improve their skill at cup pong. Since this is a popular game among college students and other young adults typically in a social setting, it has large cultural relevance among this demographic. By allowing players to get better at the game, it will aid people to feel more confident about their skill level when they are competing against others, allowing them to potentially engage in more social activities. It should also be universally known and appreciated by other older demographic groups, and our engineering approach to streamline practicing the game will be appreciated by everyone who knows this game.

Part C (Josiah): Due to the nature of the product we are developing and the purpose we designed it for, it’s difficult to claim that Splash meets many needs in the space of environmental considerations. As an aid to training a very particular skill used in games, our scope is hyperconcentrated and has little overlap with environmental concerns. At the least, our product is non-disposable and reusable, and does not contribute to electronic waste unlike other frequently trashed items such as charging bricks, cables, old appliances, among others.

This week we started our trajectory testing, a proof of concept that we can estimate the ball trajectory from just the first few frames of our camera capture. To do this, we measured and drew up a grid system on a whiteboard, threw a ping pong ball in an arc, and used a phone camera to record and manually track the position of the ball through the first few frames. Then we used classic kinematics equations to predict the landing spot. This was a simplified experiment, as not only did we have to estimate position by hand, but it was also converted to a 2D plane. During the actual project, the camera will be doing the location pinpoint and there is also a third dimension, but both those factors could be removed as we were simply testing to see if the kinematic equations would be enough. 

Unfortunately we discovered that the simple kinematics equations ended up consistently overestimating the ball’s landing spot. We found a python model online that took air resistance into account for trajectory calculations, and with that model it gave a better prediction, but still not the best. Under ideal conditions, our estimate was around 6-7cm off the mark. Following the experiments with our physics model we looked into potentially implementing more complex prediction systems into our camera or KRIA system that will give us better results. Additionally, with further testing (automated), we can determine if our predictions are accurate or precise. If it proves to be more precise in that we overshoot frequently, we could explore a basic heuristic (such as a linear shift) that aligns our precision to the center of the target.

In other news, we also worked through creating our design presentation slides. Since we now knew more about each component, we also locked down more specifics about what hardware we would be using. The Luxonis OAK-D PRO camera was picked, the AMD KRIA KR260 was ordered and retrieved from ECE inventory, and we decided to go with the gantry system. Another change with the system was that we moved the CV from being on the KRIA into the camera, as we discovered the OAK-D PRO has those capabilities. This makes it easier to transfer data between camera and KRIA, as now the camera doesn’t have to send whole frames through, and can just send coordinates for the KRIA to do calculations.

Specifically for the KRIA board, I met with Varun the FPGA TA and he was super helpful in letting me know what I would need to work through the KRIA setup, and I sent out order requests to fulfill the missing wire connections I needed to operate the KRIA.

 

 

Week 2 Specific section: Part A written by Gordon, Part B written by Josiah Miggiani, Part C written by Jimmy

Part A: Public health, safety, or welfare.

Our project solution doesn’t really have an aspect for public health, safety, or welfare. The only potential aspect is a stretch, and that is how by catching the thrown ball and thus preventing it from rolling around in the room. This minimizes the chances that anyone slips/trips on a loose ball and minimizes the need to go lift up furniture to get stray balls. Again, this is a stretch. 

 

Our project solution doesn’t really apply for this part, because our project’s use case is simply not targeted towards public health, safety, or welfare. Our project focuses more on the social aspect. We are trying to solve a pretty specific problem so we’ve considered everything and public health, safety, or welfare is not applicable.

 

Part B: Social factors

Splash has limited social factors as motivation for our project. It can be postulated that because cup pong is a social game, splash is a social aid because it helps users improve at cup pong. I would expect Splash to be most relevant to college students or young adults who are likely the largest demographic of cup pong players. 

 

Part C: Economic Factors

With regards to production and distribution of our project, we hope that our product will be designed in a way so that it can be viably be reproduced either for potential sale or by similar enthusiasts. Our system is relatively modular and easy to produce once we finish the prototype, and our ball-catching system should be consistent enough such that our functionality is not only limited to the demo portion – it should ideally work for anyone following our instructions.