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.