Carnegie Mellon ECE Capstone, Spring 2023 – Seaver Dahlgren, Erik Feldman, Christopher Hess
This week I was unfortunately not able to accomplish much work, due to being out of town for the swim NCAA championship swim meet from Monday until Saturday. Every day I was at the pool for over 12 hours, so I had very little to no downtime to do any work for any of my classes.
I believe our progress is on schedule, as Seaver and CJ are handling the work very well.
Next week I will be working with CJ and Seaver on further integration and working by myself on the WebApp.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The first potential risk was putting together the pseudo-golfball. Since the Alibaba order we originally planned no longer fits our budget requirements, we have to ensure that the 3d-printed ball screws and unscrews properly. If 3D printing is not a viable option, we have identified plastic shells that we can glue together to create the ball.
The second risk is getting the BT functionality appropriately integrated with the RPI. Currently the Bluetooth was successfully paired with an iPhone app meant for Bluetooth developers, however, the Bluetooth from the IMUs will need to be paired with a raspberry pi. The raspberry pi utilizes the BlueZ open source python framework to manage Bluetooth devices. We have done some research on this and how to park it with our IMU but we will try to implement it in the upcoming week. The IMU remains the most complicated and important part of the success of our project.
Our final risk is the course itself. Early next week we hope to build the frame and actual putting green itself. He have located all of the necessary materials for this except for green felt to give the course a putting green style. The course is a necessary piece of the system so there are not contingency plans, however, the build is quite straightforward.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
Some of the current CAD designs we have for our screwable golf ball are the following:
https://www.thingiverse.com/thing:61205
https://www.thingiverse.com/thing:3678251
https://www.thingiverse.com/thing:1648177
We will try printing each of them and test how well they work while attaching the IMU and RFID chip next week.
Other than this, there have been no other outstanding changes.
Provide an updated schedule if changes have occurred.
No schedule updates at the moment.
What did you personally accomplish this week on the project?
This week I started by identifying the new ball shape for our golf ball. Last week, we discovered that the original vendor for the ball only accepted minimum orders of 400 balls. This would be too much for our budget, so I had to scope out alternatives. I found a couple of CAD designs that we can use to 3d print the balls in TechSpark. I am going to schedule the prints this weekend. I also added a couple of new elements to the Web App. When individuals record their names on the initial webpage, the names should be stored in an SQLite database. The webpage will redirect to a new URL with the current session ID. This is where the stats will be displayed. I am currently in the process of writing the APIs that will allow the RPI to update the Stats Page.
Is your progress on schedule or behind?
We are currently on schedule. I am hoping to finish the web app APIs this weekend, so I can begin integration with CJ on the sensors and the RPI. We missed Erik this week, so I had to do a lot of work on my own for the Systems/software end of things.
What steps will be taken to catch up to the project schedule?
I am going to keep pushing forward with the APIs this weekend and Monday so that we can begin integration coming into next week. I believe that with Erik back we will be ready to integrate the whole project.
What deliverables do you hope to complete in the next week?
With CJ working on the IMU Bluetooth. We should begin integrated the whole project by next week. I want to have a working version of the Web App. I also want to be able to print the golf ball as soon as I can, so we can run the IMU on that. Lastly, we need to begin testing the IMU on the clubs and figure out if we need to use any of our contingency-planned sensors later if they are not working out.
This week we have hit the ground running. I gathered some materials to build the frame for our golf course and I am planning to start building this on Sunday. We have a bunch of wood to build a frame and to set up the course.
Personally, I spent most of my time working with the IMU. Configuring the blue tooth turned out to be harder than expected but after a bit of trial and error, I was able to successfully transmit some Bluetooth data from the IMU to my phone via a bluetooth app. (Not one that we created, just a developer bluetooth setup).
I was also able to write some code to utilize the IMU. With some tape I fixed it to a putter and was able to track the swing path as I brought the club back and then forward. I am hoping that by Monday I can have a program to say whether the user accelerated, decelerated, or stayed constant through the ball with their putt.
I would say overall that our progress is on track but we definitely missed Erik this week. This upcoming week will be a big one with the build of the course plus the integration of the bluetooth into the webapp. Another goal for this upcoming week is to have a working version 1.0 of the ball, we have identified a 3D model that we are printing to allow us to have a hollow shell that we will fill with sensors. For now making this ball mimic a real golf ball will be a nice to have in the future, but, with our schedule we may end up with a ball that does not roll perfectly.
As stated above, our biggest risk area is going to be the ball, we unfortunately had a long period of correspondence with a supplier of rubber ball shells that did not work out. The 3D printed model provides a bit of uncertainty with durabliity but I am confident we can test and find out how to maximize that balls performance.
A bit late on this one with some travel to finish up my spring break.
This week I worked on validating our sensors. I used an arduino as the MCU for all of this testing. Beginning with the RFID sensor, I was able to create a simple program to read a MIFARE compatible RFID tag and then map the UID values to a given “golf ball”. Using two of the provided RFID cards when one is tapped the program registers and reads back “Golf Ball 1 Detected!” and likewise with the other golf ball
An issue I did run into was with our tags that are used for the ball itself. This are not MIFARE compatible so they didn not register any data when scanned by the RFID sensor. However, I was able to track down another set of tags that are stickers that can be placed in or outside of the ball to provide the same function.
This week I also wrote part of the design documents. Particularly, the implementation and the design trade studies.
Overall our team is on track, I wish we had finished more this week before break, however, we are aiming to have a prototype of each of our subsystems by the end of next week and I believe we can achieve this. The biggest part of the upcoming week will be validating the IMU. I have begun to use the Arduino IDE to communicate with the IMU chip and all seems well. Our goal is to have a simulation by Wednesday that can show the orientation of the IMU as someone moves it around.
What did you personally accomplish this week on the project?
This week I created a new GitHub Repository for our web app. I created the beginnings of the framework using a Django Python framework. I also added HTML pages to represent a couple of our pages that are required for the app. I created one opening web page that enables the user to say exactly how many players will be playing on the course. The user will also have a text box where they can identify both the name of the person playing and which set of clubs and which ball each person will be using. The second page I created represents the stats page. There will be a stats page for each individual playing. The stats page will have each of the corresponding golf stats for individual players. Additionally, I drew up designs for our actual putting green. We will be using a wood frame and plywood to support the course. Additionally, we will also have a green felt grass for the ball to roll on.
Lastly, I also wrote up a large portion of the design doc. After I presented last week, it was easy to translate into the document.
Is your progress on schedule or behind?
We are currently on schedule. The team has been able to test the RFID sensor and we were able to get our initial designs approved. We submitted our final design proposal, so that is on track. With the web app currently in development we are on pace to have a working prototype before we begin integrating with the hardware side. We only need to test a couple of other sensors before we can do this. We also put in a large order for screwable balls this week, so we can actually begin rolling the balls. We also registered for additional space so we can store our actual putting green. I think we will get this extra space in the coming week. We have also received our IMU so we will begin testing that this week.
What steps will be taken to catch up to the project schedule?
What deliverables do you hope to complete in the next week?
I want to test the IMU this week. I also want to test the pressure sensors. Personally, I will be focusing on finishing up an MVP model for the Web App this week. I want the user to be able to input all of their names. Additionally, I want it to be ready to display all of the stats. Lastly, it is also essential that I figure out how to integrate the web app framework with the SQLite database. I want to be able to easily store and display data so that it is most easy to understand. I am considering adding graphs to the golf stats part of the web APP.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The most significant risk for the success of the project currently is still the IMU. We were not able to test it significantly this past week, especially with its use inside a rolling ball. The biggest issue with our IMU is that it appears to be the only IMU with built in bluetooth on the market, a feature we really want. So if this device doesn’t meet our requirements, we may need to take a step back and have to change a few things.
One contingency plan, separate from what was mentioned last week is to purchase a separate IMU and bluetooth chip and connect them with a raspberry pie. This would be more bulky, and potentially mean us changing what size ball we use, but a viable possibility nonetheless.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
No major changes have been made to the existing system’s overall structure or idea. We have determined what ball we will be using, and have ordered it. It will be modular, with two separate halves screwing together. We also have changed our RFID chip to be a smaller sticker design, that will be compatible with our RIFD scanner.
Provide an updated schedule if changes have occurred.
No schedule updates at the moment.
As you’ve now established a set of sub-systems necessary to implement your project, what new tools have your team determined will be necessary for you to learn to be able to accomplish these tasks?
The past few week after recieving all of our orders for parts we finally had the opportunity to take a step forward and look at some of the smaller details of this project. For one we realized we needed to nail down a design for our ball, whether that be an actual golf ball, a hollow golf ball, or some seperate sphere design– and we managed to pick a design. Some other smaller details that we still need to iron out: Materials for the green– we know what we want the exterior to look like, but we need to design a good support structure to elevate the green so we can have our hardware situated underneath it. A final component to think about further is the hole. We have toyed with the idea of 3D printing a custom design, so that our pressure sensor will always be touched perfectly, or just buying an standard golf hole and modifying it from there. These are ideas that our team will be discussing and resolving this week.
The week prior to spring break was a busy one. All of our original parts that we had ordered had finally arrived, Including our IMU and RFID scanner, so it was time to get testing. However with the looming due date of our design report, writing for the report ended up taking the majority of my time. We also determined that our RFID tags we had purchased were incompatible with our scanner, however CJ was able to find some smaller tags that should do the trick just fine.
I believe our progress is right on track, our slip up with the RFID tag should be no problem, as there is no real fine tuning needed for individual tags that would be very time consuming. We can get an order out for the new tags this upcoming week and be good to go. My one concern is that I will be gone for the entire week next week for my last swim meet of the season. This will put more of a burden on CJ and Seaver, but they are both productive and capable teammates, who should be able to make up for my absence.
Since I will be on the road in North Carolina all week, I will be very limited in the work I will be able to accomplish. So I will not be able to do any hardware testing or integrations. However when I find free time, I will try to continue my work on the webApp, since that is work that I can do remotely on my laptop.
This week was productive for our team. We a few of our parts arrive, to prepare for extensive testing in the following weeks. The RFID sensor and individual chips both arrived.
This week I worked extensively on web framework research. I determined that for a genuine startup, our best bet for a framework is using react on the front end and Node.JS on the backend due to the extensive libraries available, and the overwhelming developer support. However another option is to use the python based Django framework, which can cover both front end and back end in a more familiar language. While python does have its performance shortcomings, Django may be the better bet due to the short amount of time we have to develop our project.
I believe our progress is still on schedule. Next week will be dedicated to integration and component testing. Assuming all goes to plan next week we should be in a very good place for our project, and may begin work on some of our bonus features, such as focussing on our green (i.e. what surface should we purchase for it, how elevated do we need it to be, keeping it to code for multiple individuals standing on it, etc.). Otherwise we will continue problem solving, either purchasing new components or rethinking possible solutions to individual problems.
Next week our main focus will be on individual component testing. How well does our RFID sensor work? How well do the individual RFID chips work (we have multiple)? How about our IMU? These are all extremely important tasks that we will be focusing on this week. If all of them work as expected, we will start integrating via software, translating data from each hardware component into software, and storing that data in our database. If not, we will consider potentially purchasing other components, or rethinking the scope of our project.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
We think that the most significant risk is the reliability of the IMU. There was only one real option that we could find for the IMU and it is designed for ML robotics. Our IMU has to meet a few requirements: 1. It has to be able to fit inside of the ball 2. It has to have Bluetooth integration 3. It needs to have a decent resolution for the orientation. Because of all of these requirements, we are highly restricted in the number of chips we can use.
As a worst-case scenario, we believe we can use multiple accelerometers to measure ball and club acceleration. It will not be nearly as accurate, though, when it comes to pitch and angle.
So far the IMU we have selected seems to fit most of these requirements. It is onboard a small MCU that has a built in BLE unit. The MCU does meet our size requirement and is small enough to fit inside the ball. An Arduino-like IDE also comes with the MCU which should make development easier and quicker as opposed to finding a library for a separate IMU chip itself.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward? Provide an updated schedule if changes have occurred.
We finalized our design for the whole system. Here is our current diagram:
We also decided to re-scope how the overall course will look:
We changed it so there is only one starting point for the ball. This is because we thought it would be too difficult to identify a ball and use lidar in all directions. This is an acceptable compromise though because, on a real mini-golf course, golfers start from the same point each time.
Enumerate how you have adjusted your team work assignments to fill in gaps related to either new design challenges or team shortfalls (e.g. a team member missing a deadline)
1.) We have added a section to our schedule to allow for build and design time for the hole itself. With the addition of various sensors that will need to live under the course (RFID sensor and pressure sensor) we realized that the hole itself will need to be raised. This is also due to the hole itself needing to have depth. Seaver and CJ will lead the designing and build phase of this where Erik will shift to testing more of the components individually.
2.) With the raised concerns over the IMU Erik and CJ rather than just CJ will be working on the IMU data processing software for both the putter and the ball. For now, CJ will be working on the ball while Erik will be working on the putter, however, since both IMUs use the same IDE and configuration there is likely to be overlap in development here.