Tag: status report

Team Status Report for 3/30

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.

Seung Yun’s Status Report for 3/30

This week, I’ve finished up integrating the vertical aiming and radial aiming system, wired up all the circuitry, and wrote preliminary modules for controlling both axes. The servo motor only requires 5V of power, so it can be directly powered by the Pi. I’ve wrote a simple script that can translate angle input to PWM signals so change the servo’s position. I initially tried working with RPi.GPIO library, but observed some jitter. Turns out this library generates PWM signals through software but doesn’t utilize the PWM hardware in Pi, so I experimented with pigpio library which does interface with the native PWM hardware – this proved to be very stable.

Utilizing the stepper motor was tricky as well – the block connector on the stepper motor expansion board was faulty (the screw was too tight), so I’ve de-soldered the original block connector with a new one. I’ve observed that the circuitry was drawing too much current (2A) when I was playing around with it even when the motor was at rest, but that was due to not calling the cleanup code from the software side. After some experimentation, I was able to reliably control the direction and movement of the stepper. Here is a video of both system working together. I am controlling the servo and stepper by ssh-ing into the pi.

I’ve also printed out a new spinning top and servo base that can be mechanically connected together so the whole system connects seamlessly. Here are some pictures of the aiming system and the circuitry below:

I am back on track with the schedule. I am on pace to finishing up the aiming system next week.

There are some more fine tuning that has to be done – both the servo and stepper movements are too abrupt and needs some slowing down from the software side. This is especially problematic with the stepper since I observed that it is very powerful and can move the entire base (the current version’s base is not mechanically stable). By next week, I aim to fine tune the control so it is stable, and start CADing the entire robot that can encapsulate circuitry and a pole for the camera as well. I will also implement a simple server that can take in HTTP request from the frontend and communicate with the motor control modules.

Alex’s Report 03/23

This week I worked on finalizing the LIDAR for ball detection and cup detection. I have finished ball detection and I created a neat visualizer for it (from what I can tell the ball detection and trajectory detection work very well, but I am waiting to test it to make any statements about the accuracy). I am also almost done making the cup detection module, but I am struggling to figure out how to make debugging output for it.

I have assembled the launching mechanism and plan to do some math next week to see if we will need larger tubes to launch the ball. If time permits, I plan on testing it, but I am unsure about how much time I will have as I am trying to finish the CV subsystem as we have our interim presentation next next week.

I also helped Simon debug the raspberry pi’s wifi issue and I looked into how to get it working on CMU wifi (as I had to do this with my laptop). To get it working on CMU wifi I believe we just have to register it as a personal device and add the cmu wifi certificate to it.

Next week I plan on finishing CV, helping to get the system integration going and (if time permits) writing software for the launching subsystem. I am currently behind schedule. I also plan on helping mike setup the DDNS.

Michael’s Report for 3/23/24

This week I spent 2 hours in class talking about ethics and how our project relates to ethics. I spent an hour talking with my teammates about how our project stand ethically and what we can do to improve our project. After the feedback we got from the breakout session, given the time, we might implement more safety features for our robot. For 2 hours we also went to class on Thursday. For about 4 more hours I worked on the frontend and starting getting some initial feedback. I showed friend the design and they told me things I could improve about it, a big thing being making it more customized and using less base HTML/CSS assets. I am still trying to get things to align well but I definitely improved the layout with CSS. I am not the greatest with CSS so it is a lot of trial and error getting things to line up. I’m pretty much on track in regards to the gantt chart, and this week I hope to get DDNS working with Alex’s help, as he has worked with it before.

Seung Yun’s Status Report for 3/23

This week I’ve worked on implementing the software modules to control the radial and vertical aiming systems. I’ve ran into some roadblocks as I had a hard time connecting the Pi to the internet. We suspected that the issue is with the CMU Wifi as when I tried to connect using home wifi things worked out fine – we realized recently that we have to register the Pi’s MAC address to CMU-DEVICE, so we will try that in the future.

Another roadblock was that the Pi5’s ecosystem is too unstable. When Pi5 was released last October, the architecture changed significantly from Pi4, which made most of the stable packages that can interface with GPIO incompatible. Although we were able to find some libraries that work (like gpiozero), when tested on the servo the jitter was too much. We could implement the entire interface from scratch, but given the time constraints and the possibilities of more unanticipated issues, we’ve decided to use Pi4 instead for motor control – we’ve placed an order for this from the inventory.

I am slightly behind schedule as I was anticipating to finish writing all the software control modules by this week, but I hope to get back on track next week once I have the Pi4.

By next week, I plan to not only finish writing the software modules, but also to physically integrate both aiming system so we can demo the week following.

Michael’s Status Report for 3/16/24

This week I spent 4 hours going to class and working with my teammates. This week a spent 4 hours trying to implement some of the trickier parts of the font end. I spent a good chunk of time trying to figure out how to make the cups dynamic and showing missed shots on the board. I did a bit of messing aorund and eventually I was able to a grid system for the cups where you can add the coordinates of a missed ball to a list and it displays all of them. in relation to the cups. Anohter thing I am wokring on right now is curved sliders, which are not as easy as i thoruhg they were going to be to implement. I’ve looked into different packages I can use and am still trying to get it working right. In regards to the schedule, I think it could be time to get some people’s initial thoughts on the UI, as we are getting to that point in the schedule. As for the DDNS, that is coming up and I already have a head start.

Team Status Report for 3/16

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.

Alex’s Report for 3/16

This week I worked more on the trajectory prediction, with the ping pong balls, I finished the filtering of unrealistic trajectories and am now considering working on getting the trajectory that traveled the most distance. I don’t think that this component will be strictly necessary since filtering out unrealistic trajectories already works quite well. I also need to think about how to test this component of the system as well.

I thought a lot about cup detection this week because it feels harder to do than ball detection. I am going to try mapping the 3d point cloud into a 3d “pixelated” space and then go layer by layer searching for circles. Alternatively, if that doesn’t work I could use a computer vision model to detect the cups based on the rgb vision rather than LIDAR vision, but I’m trying to get LIDAR vision to work properly.

I’m almost done with the first iteration of the launching subsystem, I only need to obtain a 2 liter soda bottle to use as a pressure chamber and hook that up to our current pressure system.

Next week I think I’m just going to focus on trying to get as much as I can done with the computer vision subsystem and I might ask one of my groupmates to look for/buy the pressure container (a 2 liter soda bottle).

This puts me around where I expect to be on the schedule.

Seung Yun’s Status Report for 3/16

This week, I worked on the ethics assignment and finishing up the aiming system prototype.

I’ve adjusted the mounting point for the vertical aiming system’s arm, which was further away from the previous version, making it more stable and easier to screw in. The servo motor house’s mounting point has also been re-printed and everything was assembled nicely.

As I was about to work on the electrical connections, I’ve realized that I don’t have the appropriate wires. For the servo motor, the three wires coming out of it are all lumped in a female dupont connector, and the stepper motor has bare cables coming out of it. I’ve ordered dupont cables and block connectors so I can make all the wired connections come together.

I am still on schedule according to the Gantt chart.

For next week, I will be making a final push so that the aiming systems all come together. While I wait for the new parts to come in, I will be working on enhancing the prototype so the vertical and radial aiming systems are connected, as well as the base for the robot. Once I have the parts, I will be writing control modules for each system so I can demo that in the following week.

 

Team Status Report 3/9/24

There is risk of users not finding the front end intuitive as the front end is not quite ready for testing yet. We still have the risk of the pi’s processing power being a bottleneck for our computer vision. The pressure chamber we plan on using is now a 2 liter soda bottle because it is easy to buy and work with as well as being environmentally friendly. We decided we can push back front end user testing by one week, as Mike is still implementing the front end. This push should overall be inconsequential as there is a lot of time left to test and make changes. Scheduling wise Alex feels like putting lead time for parts on the gantt chart would have been useful in retrospect, but that is also nearly impossible to plan for and would go over the 1 week limit that is allowed on the gantt chart. 

Part A was written by Mike:

One global impact is the digital divide.  The digital divide is the gap between different groups of people with access to modern technology and those who do not. In order to address this concern, our project needs to be accessible to people who may not have a lot of experience using technology. One way we can achieve this is by making our UI have guides that can help people less familiar with navigating the web. Another global concern could be certain cultures being feeling excluded using our project. In order to mitigate this, we are making the UI as simple as possible, making it culturally neutral and universally appealing. Overall, no matter where you are in the world, as long as you have a device that can access the internet we want pong pal to be a fun experience.

 

Part B was written by Seung Yun:

Water pong and its variants are a huge part of American social culture. Quoting from the book “The Book of Beer Pong”, the game “has transcended its obscurity of dorm rooms … it’s infiltrated bars, tailgates, corporate parties, and even wedding receptions … the very heart of the American spirit”.

PongPal lowers the barrier of entry to this game, allowing anyone around the world to partake in this cultural tradition. Moreover, it promotes inclusivity by allowing anyone to play the game with internet access.

 

Part C was written by Alex:

Our design for PongPal includes using a 2 liter soda bottle for the pressure compartment, this demonstrates our resolve to use sustainable materials wherever possible. We also reuse a raspberry pi 5 and an intel realsense L515 LIDAR from previous years showing that it is possible to make an impactful project while also remaining environmentally aware. Overall, PongPal is fairly orthogonal to environmental factors as it is essentially a substitute to a player in a game of pong. One could say that it is environmentally friendly since it only really requires electricity and compresses its own air (our initial designs used compressed air), but the human(s) that it replaces are ultimately also resource efficient.