Posted on

CJ’s Status Report For 4/8/2023

This week went very well as well. For our demo we wanted to have was a full demonstration of the putter setting up their ball, taking their putts, and tracking the distance with the webapp. We then wanted to demonstrate the sensor system to tell when a putt is made. Finally, we wanted to have a demo of tracking spin rate and putter speed with the IMU.

After a laborious Sunday, we were able to achieve most of these goals. It started out for me by walking the entire course down Forbes with a few of my friends after realizing the 10 foot by 5 foot course wasn’t going to fit in the back of my car. Going to call that walk my workout for the week, grabbed some food and it was off to the lab. We set up the course and configured the LiDAR. Leveling the course was harder than expected as the LiDAR needed the entire course to be very level in order to properly find the outline. Once that was done, I finished implementing an algorithm to calibrate based on the course outline and search for “ball-sized outliers”.

Now that we had this performing, we set up a small LED system to represent the RFID and the pressure sensor being triggered before trying to configure them with the webapp. Seaver spent some serious hours getting the webapp to work and deployed.

Finally, we threw some post requests into our codebase for the LiDAR and Arduino based sensors to communicate with the webapp. Our downfall pre-demo was the operating the IMU. Unfortunately, we did not receive our batteries in time so that made it impossible to communicate with the IMU while it was in the ball. We were pretty burnt out by this point anyway, so we set up a small sub-demo of the IMU where it was still wired up.

Overall, we are set for the coming month and have some work ahead of us. Next big tasks are working with the IMU once we receive the batteries and putting the felt on the green to slow the roll of the balls. Regardless our schedule is on track, but we will need to make a push this week with testing.

The next tests for me to perform are verifying the distance measurement of the LiDAR and the accuracy of the IMU.

Our LiDAR test is quite straight forward, we plan to place the ball in  25 different spots that vary both distance and angle to the hole, measure the distance with a tape measure, then measure the distance with the LiDAR. From there we can continue to calibrate or verify that it is within our specification of 3 centimeters from the true distance.

The IMU test is a bit trickier, for this we will roll the ball along a path of length 3 feet and time it. This will give us the average speed over that distance. We can then extrapolate the spin rate as this will be based on the speed and circumference of the ball. Comparing this to the measurement of the IMU will tell us if we are within 5 revolutions per minute as per our specification.

Posted on

Seaver’s Status Report for 4/8/2023

What did you personally accomplish this week on the project?

This week we had our interim demo. I worked on setting up endpoints for the demo. I modified the current web app implementation so that users can assign names to a specific type of ball that way a user is easier defined and it can be queried from the database. I also added endpoints to modify the distance the ball is away from the hole for each person. I worked with CJ to have this updated in real time during the demo. I also set up the IMU so that we could get a graphical representation of how it looks when you pitch the club in different directions.

Is your progress on schedule or behind?

We are currently on schedule. I am going to continue working on the BT for the IMU this weekend so that we can begin full testing for each of our components.

What steps will be taken to catch up to the project schedule?

na

What deliverables do you hope to complete in the next week?

Haver the IMU BT set up by next week and have preliminary testing of “ball hits” as well as balls made. I would also like to put the IMU inside of the balls and see the accuracy there.

Now that you are entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

I am planning to run all of the “Distance-to-Hole,” “pair ball”, “stroke accuracy” and “holes made” tests. I will be performing these tests as per our design doc. this week. These are less modular. I will use the whole system, including the sensors, to perform these tests. So far I have only written some unit tests for the Web App. I want to run a couple more integration tests and reliability tests. I have run into a problem a couple times where the server fails to create a new game for some reason.

Posted on

CJ’s Status Report For 4/1/2023

This week was another productive week.

This week i personally spent my time working on the course itself and the LiDAR. I spent many hours building our wooden course. After building it, I recruited a few fellas to carry it down to campus with me.

I also worked on the LiDAR and was able to consistently track a ball. I ran into an issue where balls that were behind each other were unable to be tracked. We may consider re-scoping our project to only allow for one ball to be on the course at a time so that the LiDAR can accurately track the ball. However, the LiDAR implementation was vastly improved to track not only the ball but the hole and the distance to the hole. The LiDAR now also makes  POST request to the webapp to send the distance to the hole.

I think we are on schedule and plan to have an amazing Sunday to prepare for our demo where we want to have IMU data with the putter and ball as well as the hole, LiDAR, and RFID all working well with the webapp.

Posted on

Team Weekly Status Report 04/01/2023

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?

At this point, there are only a couple of aspects our design is missing. The first is the full integration of the BT for the IMU. This should not be a huge blocker anymore. Seaver was attempting to integrate a BT library on MacOS, but we have decided that Linux may be a better option for integrating BT with the OS. MacOS tends to be a bit less lenient on using some of the low level functionality like Bluetooth.

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?

One design change we had to make was the location of the LiDAR sensor. We had to move it to the center of the course in order for it to get a better view of the course. We also have considered adding other restrictions to the length of the course because the LiDAR resolution is not good enough. CJ has discovered that the sensor can sometimes be unreliable, we will attempt to get a percentage this week of how often we can count on its data. Part of the problem is it sometimes just freaks out and loses the location of the ball at seemingly random times.

Provide an updated schedule if changes have occurred.

We are up-to-date with our current schedule.

 

Posted on

Erik’s Weekly Status Report 04/01/2023

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week I focused on transforming the API’s of our webApp from REST to graphQL. This was done due to the fact that we were creating an exceedingly large number of endpoints due to the various different functions that our webApp would handle. Updating ball distance, starting a new game, ending a game, were all required different endpoints using a REST API, therefore we decided to work on transitioning to the project to graphQL to have only one endpoint, with a large variety of Json like inputs. I was able to successfully setup graphQL and successfully update the database using it on my branch of the codebase. While there is more to add, this is a very promising start on the API migration, and hardest part of the migration.

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I believe our progress may be a bit behind, simply due to the fact that many of our orders have been taking much longer than expected to arrive. We have ordered a battery, some “artificial turf”, and compatible RFID chips, which all have not arrived yet. This is unfortunately slowing down our integration, and potentially leaving us with a less fleshed out Interim demo then we would like. This issue should be easily resolved once the parts arrive however, as we have been doing great work integrating the rest of the components, so once these pieces finally arrive, the last few steps should be quite manageable.

What deliverables do you hope to complete in the next week?

By our iterm demo on Monday, I want us to be able to show functional ball tracking in a solo putting game, and accurately keep score of hits, and when the player finally makes it in the whole. Assuming our IMU battery, and other essential items arrive this week, we should be able to have accurate feedback on speed and club angle/ball path as interesting data metrics for our demo as well.

Posted on

Seaver’s Status Report for 4/1/2023

What did you personally accomplish this week on the project?

I fixed the IMU code so that the Bluetooth now transmits floats instead of just single bytes. In the mobile app that pairs with the IMU, I also modified the settings so that it displays transmitted data as floats instead of hexadecimal values.

Erik has been working on implementing a GraphQL endpoint to simplify making changes to the backend DB. In the meantime, I augmented the homepage, so that there is a new game button that goes to the new game page. I also added functionality so that the stats page updates every 0.5 seconds. It is a bit inefficient at the moment, so we may want to switch to using AJAX in a later implementation.

Is your progress on schedule or behind?

We are currently on schedule. We will be wrapping up the integration of the LiDAR to the web app tomorrow. On the web app side, I want to deploy the app using Heroku. Perhaps we can use Kubernetes? We will finalize it tomorrow.

What steps will be taken to catch up to the project schedule?

Just need to work hard tomorrow to be ready for the demo.

What deliverables do you hope to complete in the next week?

We need to integrate the LiDAR, RFID, and pressure sensors into the web app. I will work with CJ on how the data will be processed before sending it to the web app. I also will work on looking for alternatives to host the web app itself, so that many devices can make POST requests to augment the database.

Posted on

Team Weekly Status Report 03/25/2023

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?

Right now the most significant risk that could jeopardize the success of the project is still the IMU. Fortunately for our team we have been able to calibrate the IMU and read out accurate measurements of acceleration and velocity. However our major roadblock at the moment is making the built in bluetooth functional. Using the packages the manufacturer of the IMU recommends, we have only been able to send one byte of data at a time, as a message (string) that is over a byte long simply gets truncated and only the first 8 bits of data are received. We believe that there is a solution, as forums online have talked about using an older driver for the IMU can fix this issue. We have also considered the idea of doing the computation on the IMU, as it has a fairly powerful microchip on it. But in case all of these options fail, we are fully prepared to move on to a new IMU (with external bluetooth chip) on Wednesday, and increase the size of the ball to house it if needed.

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?

As of now, no changes have been made. We have solidified the design of our “golf ball”, by 3D printing it as a screwable design. The prints are very smooth and roll very well, with plenty of space to house our current IMU and battery design.  (I would post a picture but I sadly left the 3D printed balls at school) We have also decided that our frontend will be developed in react, which should pair nicely with our Django backend.

Provide an updated schedule if changes have occurred.

We plan to have accurate ball distance (LIDAR measurement) and hit and make detection (IMU and pressure sensor) of a single ball integrated by our project demo. This puts us slightly behind pace as to where we were a few weeks ago. However this still gives us plenty of time to fully complete the 3 player mode with accurate measurements about each putt.

Posted on

CJ’s Status Report for 3/25/2023

This week was quite productive.

After our ethics lecture we sat down to figure out the remaining details of the project. All our materials have been gathered and we ordered the last of our components. These included some felt for our putting green, a few more IMUs, and the RFID tags.

Personally, I spent some time working with the LiDAR sensor to create a better ball detection program. So far so good, however, the testing has limitations in the space I was in. Last week I started building the course but we are meeting at my house on Sunday as team to finish the frame of the course and bring it to campus Monday. Once we have that complete, we will be able to begin integration.

The remainder of my week was spent on bluetooth debugging. Turns out, bluetooth is quite difficult. The built in package that was supplied to us from the manufacturers of the MCU with BLE and the IMU was deprecated and was unable to compile, after some head scratching and some stack overflowing, I decided to just start from scratch. I created my own implementation and was able to successfully pair with both my phone and a computer.

Small change in our implementation is due to some of the things I discovered with the bluetooth, it does not send data very fast, so, we are now planning to do a lot of the IMU preprocessing on the MCU to generate a quick and easy JSON output that can be fed into either a laptop or a raspberry pi. This JSON will take the data from the IMU and convert it into velocity to send to the laptop or pi.

We also were able to mount an IMU on the putter and hope to do detailed tests this upcoming week.

Overall, we are on schedule, but we sure have some testing to do. I think these coming weeks will be fun, challenging, and long, however, I am ready to attack this project with a sight at the finish line.

Posted on

Erik Feldmann Status Report 03/25/2023

This week my primary focus was establishing a front end for our webApp. While I was gone at NCAA’s the prior week, CJ and Seaver made great progress integrating our hardware and webApp together, with Seaver focussing on the backend of the webApp, and CJ focussing on the hardware. This left me with the opportunity to start work on the frontend, as that is the one aspect of our project we had not touched yet. I am working on the front end in React JS, something I am unfamiliar with. I am learning a new language, so its taking me longer than I would like to create an established product. However, I have full confidence I will become proficient in React (and JavaScript) by the end of the semester.

I believe we are well on schedule considering the integration we have accomplished so far. The one place we are lacking on is our physical green that we need to build, and we plan to address that tomorrow (03/26), and get started building.

Next week I plan to push a working front end to production, leaving us with a nice webApp that looks like a bit more than HTML. Also as a team we plan to have the green at least partially assembled, with the skeleton frame of the wood put together. We placed an order last week for our “grass”, and we are 3D printing balls and a hole. All in all, our project is coming together quite well.

Posted on

Seaver’s Status Report for 3/25/23

What did you personally accomplish this week on the project?

This week I finished the Backend APIs for the web app. Everything now should be stored in an SQLite Database. The users can input their names and submit them via a “new game” page. They are then redirected to a stats page which will display every user’s real-time stats. I also shared the repo with Erik and CJ so Erik and do more of the front-end design using react. Lastly, I also picked up the extra IMU and made additional orders for more sensors, so that we can have 3 independent sets of clubs and balls. This included the purchase of RFID tags and more IMUs.

Is your progress on schedule or behind?

We are slightly behind as of right now. I wanted to have Bluetooth fully integrated with the system, but we ran into a couple of issues. Some of the serialization protocols are not working as they should. We are only able to send one byte at a time.

What steps will be taken to catch up to the project schedule?

I am going to work with CJ simultaneously to get the Bluetooth working for the IMU. We have two IMUs so it should be faster. Meanwhile Erik will polish up the frontend look of the website

What deliverables do you hope to complete in the next week?

We need to send the data from the IMU over Bluetooth, to the local computer. The local computer should then make a post request to the web app. Our main blocker and focus right now is working with Bluetooth. Everything else (all of the other sensors) can be wired directly into the local computer.