Author: seungyul

Team Status Report for 4/27/24

As we approach the final demo next week, the only risk that remains is the parts failing. To mitigate this, we’ve made some spare parts that can be replaced on the fly. For example, we have multitude of motors for the pressure system, and we have replacement parts for all parts of the pressure system’s tubing. The aiming system also has a backup motor and motor drivers in case it fails.

We don’t have any major design changes this week.

We don’t have any schedule changes this week.

We’ve performed lots of unit tests and overall system tests recently. We’ve did individual unit tests for vertical and radial aiming system. The pressure system had reliability testing by shooting in the same setting multiple times. The vision system had accuracy testing by detecting the ball’s landing spot and cup’s true location. We performed user testing on our frontend. For the final integration testing, we’ve ensured that having the same setting yielded consistent landing location.

We were able to use the values from the testing for calibration. For example, the voltage reading from the pressure sensor was measured during testing to see what is the appropriate range for the game – we’ve found that 2V – 3V is the sweet spot, and have decided to use this range that users can actually set.

We haven’t made any significant design changes while testing, as the results passed our expected criteria.

Seung Yun’s Status Report for 4/27/24

This week I’ve spent most of the time making minor adjustments to the aiming system to get it ready for the final demo, and working on the final presentation & poster & paper. I’ve also printed the camera pole for the LIDAR camera. As we’re integrating the pressure system with the aiming system, the weight of the pressure system put a lot of stress on the aiming system, so I had to make some adjustments such as slowing down the servo motor movement and increasing the speed of the stepper motor movement so that the whole thing moves more smoothly. Below is the final image of the finally assembled robot.

I’ve also worked with Alex and Mike to software-control the pressure system, and ensuring frontend calls the right endpoint on the pi.

I have finished all my task and is on schedule.

I will be ensuring everything works as expected and work more on final deliverables next week.

Team Status Report for 4/20/24

We have lots of spare parts for the physical systems that mitigates most of the risk related to hardware failure. As we’re more or less done with individual subsystems, the problem could still arise as we’re integrating different subsystems. For example, the computational power difference between the Pi and the computer we’ve been testing the vision system on could lead to issues – we don’t anticipate this to be a problem, but worst case we do have a more powerful Pi (Pi5 that we didn’t end up using) so do these processing. Another problem that could be an issue is the motor shaking messing with the computer vision but we can avoid this issue through our software, to do so we simply don’t run any of the computer vision subsystem while the motor is running.

We have no major design changes this week.

We have no schedule changes this week. We will be focused on testing and integration for the rest of the semester.

Seung Yun’s Status Report for 4/20/24

For the past two weeks, I’ve focused on cleaning up the aiming system and preparing for the overall integration. I’ve refactored the code to remove the unnecessary ipc communication between the networking module and the motor control modules.

As the pressure system by Alex is working properly, I’ve redesigned the robot for full integration. Given that the pressure system’s pipe is rather thick and will need some spacing to bend properly, I’ve moved the balancing bridge on the lazy susan plate to the front and elevated the whole thing. I’ve also printed out a pole for the camera so it will be elevated by 50cm from the surface, and the whole base for the robot. The new physical robot looks like below:

I’ve also performed testing on the aiming system. I’ve set the angle of the vertical aiming and radial aiming system to various degrees, then took a picture of it to analyze the angle using an online tool like below. I’m still compiling the results of this to be included in the presentation next week.

I am on schedule according to our Gantt chart.

Next week, I will work on writing software on the pi to control the pressure system and put everything together, and work with Alex to run the vision algorithm on the pi, and work with Mike to connect the frontend to the pi properly. We’re at the integration mode and the lines between our responsibilities are rather blurry.

Throughout this project, I had to get out of my comfort zone and work with different tools – the biggest probably is CADing and physical design. I’ve only taken CAD class last semester and was new to laser cutting. I’ve had to read up on lots of other reference designs to design our robot. I’ve also asked for advice from Techspark and IDeate staff to make sure our design is feasible.

I’ve also had to learn how to work with microcontrollers, such as writing modules for motor controls and networking. I’ve followed lots of online tutorials to get the initial setup, then relied on documentation of specific libraries I was using to tune the code to our purposes.

Team Status Report for 4/6

The risk of the pressure system remains the biggest as of now. We’ve noticed the pressure is not leaving the tube as quickly as we hoped and making adjustments, but the new design might still encounter this issue – we are exploring mechanical shooting mechanisms to mitigate this risk. The hardware’s stability is also an issue. As we’ve experienced hardware failure on the microcontroller this week, having spare parts to mitigate this is going to be important.

We have no major design changes this week.

We’ve updated our Gantt chart this week to match the progress we’ve made. The cup detection and the pressure system has been moved back a little bit, and some of the workload has been re-distributed. The updated Gantt chart is attached below:

As we approach the last stretch, we have multiple verification and validation plans in place. For verification, as discussed in individual reports as well, the aiming subsystem will perform a series of movements and take physical measurements to verify it works.

For the validation, once all systems are built, we will test the system by launching the ball in the same setting 10 times to a grid paper, and note where it landed. As mentioned in design presentation previously, if we can draw a 2cm * 5cm bounding box on all the landing spots, we will have successfully validated our project.

For the computer vision ball detection validation, we will measure the accuracy by positioning the LIDAR sensor facing up. Then we will throwing a ball over the LIDAR sensor and record where it lands on the ground. We will then compare the actual landing location to where the LIDAR predicted. We will then measure the absolute magnitude of the difference between the two points. We currently plan on doing 50 trials.

For the computer vision cup validation we plan on setting up the cups and then moving the cups around and measuring the distance between where the cups are predicted to be and where they actually are, similar to the method used for ball detection. The main difference here will be that we need to map out in 3d space where the cups are relative to the LIDAR so it will be more of a pain to set up, but once we have our measuring set up and validated, we will be able to quickly collect data.

Seung Yun’s Status Report for 4/6/24

This week was a strong push for our mid-demo. I finished up writing the backend code on the RPi, so that the robot’s aiming system can be controlled both using the ssh’d terminal, and the frontend. While I was working on it, the RPi we were using suddenly got bricked, so I had to scramble to find another RPi last minute to finish this up before the demo on Wednesday. I suspect that this is due to high current drawn by the motor as when I was working on it on the new pi, the previous motor driver seemed to be damaged. Here is a video of the working demo in which I control both aiming using the frontend.

I am pretty much done with the aiming system and ahead of schedule – we updated our Gantt chart this week to align with our actual progress more closely.

Next week, I aim to tidy up the code so that it doesn’t run on three processes, and make the system more robust by ordering some backup parts. Since I am done with the aiming system, I am shifting my attention to help the shooting system. I am exploring alternative shooting mechanism that involves a more mechanical approach such as a spring. By next week I aim to have the alternative shooting mechanism designed and have the parts ordered, along with the robust aiming system.

Moreover, for the verification, I am planning on setting the aiming system at a certain angle, and measuring the physical angle. For example, I will send a series of angle settings for the vertical system, and use a protractor to verify. For the radial aiming, I will mark the “front” with a paper below the robot, move it a certain degrees, mark the new front, then measure the angle moved using a protractor to verify it matches the angle it was supposed to move.

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.

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.

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.