Tag: status report

Alex’s Report for 3/9

Over the last 2 weeks I have spent considerable time working on the ball detection part of the computer vision subsystem. As seen on the design report, we can now pretty reliably detect ping pong balls that are flying through the air. I have also finished the trajectory prediction with the ping pong balls, I still need to filter out unrealistic trajectories, but that shouldn’t be too bad and I am looking forward to testing that component soon.

I have also spent considerable time working on the design document.

Over spring break I was able to retrieve some of the parts for the launching system and I began assembling the launching subsystem with the parts that I had available. I am looking forward to receiving the remaining parts and then I want to finish building the first iteration of the launching mechanism.

This leaves me on track with the schedule.

Next week I plan on finishing construction of the launching mechanism and getting some progress on the computer vision subsystem (I will probably focus on trying to finish the computer vision subsystem).

Mike’s Status Report for 3/9/24

This week I spent 4 hours collaborating with my team mates in class. Also, I spent 4 hours working on the front end. I kept working on the UI in React, and got it to a place where I feel comfortable focusing on getting the communication between the raspberry pi and the frontend working. During break, I learned what Express.js is and how it works, and I got a basic endpoint to receive posts from the frontend, be it changes in the robot or the fire action. I spent some time learning how Duck DNS works and tried to get a link between the pi and frontend, but after lots of trial and error I couldn’t get the rpi to register the requests. Alex recommended to me and knows to use duck dns , so we are going to trouble it shoot it when we get back from break. As for the gantt chart, we are just getting to front end user testing, so I am a little behind, but I think I can get the front end to a testable point later this week. It’s not a huge issue as we are ahead in other places, and I am looking into DDNS even tough that isn’t until next week. Lastly, I spent a lot of time helping with the design report.

Seung Yun’s Status Report for 3/9

The past two weeks (but mostly week before this), I’ve continued on iterating on the vertical aiming system and the radial aiming system. I’ve also worked on writing the design review report that was due last week.

For the radial aiming system, I’ve laser cut a new plate that is compatible with the flange coupler, and attached them all together. There are few more details to flesh out such as finding the right screws (I’ve been using the spare ones in TechSpark so far) and not messing up the actual cutting so it’s round, but the prototype feels stable.

For the vertical aiming system, I’ve made some mistake in CADing it so the house for the servo motor didn’t come out well, but the arm in which the barrel will sit came out nicely. Similar to the radial aiming I still need to find the right screws to attach the arm to the servo motor in a correctly aligned manner.

I am still on schedule according to the Gantt chart.

For next week, I will start connecting the radial aiming systems’ electronics, and write some primitive control module on the Pi. For the vertical aiming, I will re-print the servo house, and finalize the physical structure. I will also slowly start thinking about how to integrate both systems.

P.S. I went to a museum during spring break and found something that could be an alternative vertical aiming system design.

Team Status Report 02/24

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.

Alex’s Status Report for 2/24

Time Breakdown:

  1. Class time (4 hours)
  2. Ordering Parts (2 hours)
  3. Design Document (2 hours)
  4. LIDAR (4 hours)

This week I was in class for 4 hours watching presentations.

This week I ordered a good portion of the parts I need for the pressure subsystem. Additionally, I’ve looked into some alternative parts that we can buy and am considering buying them just to see if they can be used to improve our base design. These include buying a simpler solenoid valve for the firing mechanism and weighing some options on different PVC pipe radii/thicknesses that I can buy.

This week I also worked on writing up some of the back of the napkin math that was used for our design process to include in our design document. This mainly involves the pressures necessary to launch the ping pong ball with sufficient velocity.

Finally, this week I worked on the LIDAR system. First I verified that it can indeed track a ping pong ball at the distance we require (it can). Then I began working on the software to interface with the LIDAR, I was having some trouble on this front, but I will be finalizing the software for this subsystem over the coming week.

This leaves me behind schedule on ordering parts, but ahead of schedule on getting the LIDAR to work.

Next week I plan on working on ball detection with the LIDAR as well as beginning assembly of the pressure subsystem.

Seung Yun’s Status Report for 2/24

This week, I worked on practicing for Design Presentation (and actually delivering), and working on the construction of the radial aiming system. The stepper motor was delivered early this week, so I took some time to iterate on the prototype to think about the actual connections of the individual laser-cut components, and how to attach the base to the shaft of the motor.

The stepper motor house came out nicely – I am a little worried about the flatness of the motor, so I will probably end up adding a bottom plate for the motor house. The lazy susan plate poses a bigger mechanical challenge as it doesn’t fit very tightly to the shaft. To mitigate this, I’ve ordered a Flange Coupler, which will be fastened onto the shaft, and the next version of the plate will have holes cut into it so that it can attach with the flat part of the coupler.

While trying to test driving the motor, I’ve realized I need a stepper motor driver (DRV8825) on top of the motor to actually interface with it, and also to protect the hardware from current surge – I’ve ordered stepper motor driver this week so I can start trying to control it on the Pi.

My schedule is still on track as this week and next week is building the first version of the vertical and radial aiming system and finding out what problems I might encounter, as I have done this week.

Next week should be relatively busy with the Design Report, along with additional parts such as the ones I’ve ordered this week and the servo motor should be delivered. I aim to deliver vertical aiming system’s prototype and finalize the radial aiming system’s mechanical portions.

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.