This is the last week of school. Earlier this week Pat and I set up the poker table and final integration of subsystems for the presentation. I presented the slides on Wednesday. After that, we have been working on the poster and final video. Good thing we tested our over-all system earlier so this week we just been working on the group assignments. I am also recording the video and talking about the servo subsystem and overall system. Very excited to see how this VR presentation is going to work.
Zongpeng Status Report 5/1/21
This week pat and I met and tested servo integrated with GST. Servo is pretty robust. We made some small changes to the angles that we are rotating to the player. We tested the robustness of servo by constantly feeding it an output from game state tracker, and input that output which contains player angle to the arduino through serial communication. We did that like 20 times and each time servo rotates to the correct position and the speed is under a second, both of which exceeded our original metrics. Now, servo subsystem and integration of servo and GST is done. Next step we will set it up at a real poker table for the demo.
Zongpeng’s Status Reports 4/24
This week I have been designing and thinking about poker logic and stack/pot-size logic on paper. Then I met up with Pat on Saturday to integrate these logics into the actual GST and UI. I uploaded the drawing and examples below. We keep track of the player order in a list and update it after each action. The first player in the list is always the current player to act, so instead of explicitly tracking who the big blind, small blind and dealer are, we simply imply those positions in the list to simply things. For updating bet size, and pot size, our plan is to have a bet_list as an attribute in each player class. With this list, we can update player’s stack size and pot size in real time instead of updating them after each round.
Pat and I got a lot done in terms of integrating the most important part of the poker logic this weekend. There are more pictures from the actual UI in Pat’s posts. Next step we just have to implement stack/pot size logic which shouldn’t be too bad because I have a concrete plan on paper and we already did the player order logic. Last part would be rotating the servo. Since we already set up the serial communication between GST and Arduino, We will just hardcode the angle for each player and send that information to servo every time the player order list changes.
Attached below is handwritten notes of poker GST logic and potsize/stack logic. Apologies for the messy handwriting.
Zongpeng’s Status Reports 4/10
Pat and I worked this week to integrate the GST and servo. We were able to control the servo from the GST. We used pyserial in GST to send angle information. For Arudino we just opened the port to constantly receive information sent from GST. However, the poker logics hasn’t been fully implemented yet, so we are hardcoding the rotation right now. We plan to show integration of servo and GST during our demo Wednesday. I also printed out the 3d components and assemble them together. One problem is the standoff we ordered are not long enough so I will go to home depot tomorrow to see if there are longer ones. Otherwise might need to order from Amazon. Everything is looking good. Next step is probably figure out the actual poker game logic and tried to integrate the camera with the GST, and if we have more time, we can add additional feature Gary mentioned, which is feedback from the camera to pi and pi to servo to make sure we pointing to the stack accurately.
Zongpeng’s Status Reports 4/03
I went to tech spark and we should get back the 3d printed components on Monday. I also worked on the serial communication between Raspberry Pi and Arduino. Once Pat is done with GST, we will start integrating the servo and GST subsystem.
Zongpeng Yu’s Status Report 3/27
So we decided to make some changes to the servo subsystem. Instead of hooking the servo up directly to raspberry pi, we hooked it up to Arduino instead. The reason for this is because Raspberry Pi’s GPIO pins aren’t able to reliably read feedback PMW from the servo. Attached is a video of servo spinning 90 degree each second. it is also capable from rotating more than 360 degrees if we want to thanks to it being a continuous servo. The library i used is from here: https://github.com/HyodaKazuaki/Parallax-FeedBack-360-Servo-Control-Library-4-Arduino. Next step I will set up the serial communication between Raspberry Pi and Arduino so the GST(game state tracker) could send me the location where the servo should turn to.
Zongpeng Yu’s Status Report for 03/13/2021
I picked up all the parts this Friday. However because I had a bunch of midterms this week I wasn’t able to do much. I did set up raspbian so next step will be hooking up the servo to the board and set up i2c connections and use servo library to do some simple testing. Once thats done, I will need to talk to Pat who’s in charge of dealer software and game state control to figure out how to rotate the servo based on which player is in action.
Zongpeng Yu’s Status Report for 03/06/2021
Our team worked on the slides for design presentation. Since I was not home for the past 2 weeks, I didn’t have the pi on me. However, I did look up how to set up rasbian OS, read the syntax for adafruit servo library to control the servo, and learn how to configure i2c for the adafruit motor driver. The code shouldn’t be too bad so I planned to start writing the firmware for servo after the midterm week and finish it in a week. I think the most challenging part is to integrate everything together so we might dedicate more time for the integrating phase.
Zongpeng Yu’s Status Report for 02/27/2021
This week I looked for motor that we gonna use to spin the camera. We decided on using a servo because we can have it rotate to an exact location. Also there is no need for motor controller because we are only having one servo and we need external power supply for it.
The part i picked is a 360 continuous rotation servo with feedback from adafruit. With the feedback, we can determine the location/rotation of the servo and we could use PWM to let it rotate to certain player’s position. Also this servo provides enough torque to support the camera on top of it.
The link is: https://www.adafruit.com/product/3614?gclid=Cj0KCQiA-OeBBhDiARIsADyBcE4ks19fWb6nEjYKXbqq6JSbYBFpyEwgnjR2dLRSK4ZkQxkaQgekr6MaArZCEALw_wcB
Servo driver: https://www.digikey.com/en/products/detail/adafruit-industries-llc/815/4990757?s=N4IgjCBcoLQBxVAYygMwIYBsDOBTANCAPZQDa4ArAEwIC6AvvYVWSHGBSIWAGwAESABboAdiNyYQDIA
Brandon also shared a servo on raspberry pi tutorial: https://learn.adafruit.com/adafruit-16-channel-servo-driver-with-raspberry-pi/using-the-adafruit-library
Zongpeng Yu’s Status Report for 02/19/2021
Like everyone else mentioned, we pivoted our design. What I did for this week is thinking about the positioning of the camera/cameras so occlusion won’t become an issue. We will need to add some constraints(designated area on poker table) to where players have to put their stack and bets. I am still a little uncertain about where the pot size has to go because normally people put those in the middle of the table. However, if our camera is in the center, the pot will block off player’s bet and stack size. One way to avoid this is to raise the camera in the center so it is viewing players stack and bet size at an angle. However, I am not exactly sure how the computer vision software can handle this.