Author: akireeff

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.

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.

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.