Project Journal for - Krish Kumar

=============== Week 15: 29 hours 45 min (Cumulative 173 hours 15 min) =================

Entry 7: -----------------------------------------------------------------

Date: April 24th
Start Time: 11:45am
Duration: 4 hours 45 min

For this session I:
Session 8
• Started final testing and polishing for the final demo.
• Met with team (Brendan, Johnny, Craig) in lab to finalize the project.
• Worked on running full integration tests across all the game modes.
• Helped debug game mode issues where duplicate cards were being detected or some cards were not detected at all.
• Worked on updating computer vision code to always output a full deck of 52 cards, even if some cards were missed or duplicated.
• Set it up with following logic:
   • Store first best guess with card prediction and probability
   • Then go through and look for duplicates
   • In case of duplicates pick the higher probability and assign the other card any card that has not been selected
   • Look through if a specific slot has not been assigned, assign it the remaining slot
   • We chose this method because even though this was not ideal, it was the only way to not require a complete overhaul and not require recursive processing, both which were slow and computationally expensive
• Implemented logic to assign missing cards to lower confidence duplicates.
• Tested all modes like random shuffle, royal flush, and phone number game modes to ensure proper operation.
• Attended final presentation with the team at 4:30 pm where the demo went very well.
• All modes ran successfully except for one minor computer vision issue during the phone number game demo.

Entry 6: -----------------------------------------------------------------

Date: April 23rd - 24th
Start Time: 8:15pm
Duration: 12 hours 15 min

For this session I:
Session 8
Session 8
Session 8
Session 8
• Worked through the entire night with the team to debug final system integration issues.
• Focused on improving computer vision by retaking images for reference decks after camera alignment shifted.
• Discovered obstruction in camera lens with Johnny and Brendan, and helped clean it out by disassembling camera module.
• Removed the camera and unscrewed the lens to clear obstruction
• During this, feeder's hot glue detached from PSU
• Reattached camera and tested computer vision again
• Accuracy was very low due to slight change in camera position and focus during cleaning
• Started retaking reference pictures
• Used command-line camera script I had written earlier
• Used send_commands to feed different slots for image collection
• During testing, feeder stopped feeding properly — front motor stopped working
• Hooked motor directly to another 12V supply — motor itself was fine
• Verified all connections and PWM signal — both were good
• Determined the motor driver had failed
• Worked with Johnny to try removing the motor driver chip using ChipQuik and heat gun.
• Attempted to desolder motor driver from old PCB but ended up damaging some pads in the process.
• Switched focus to helping team get backup PCB fully working.
• Tested computer vision after new PCB was brought up and verified system functionality.
• Helped retune vision cropping parameters to fix image alignment and improve detection rates.
• Stayed overnight in lab to ensure everything was functional by morning.

Entry 5: -----------------------------------------------------------------

Date: April 23rd
Start Time: 3:30pm
Duration: 2 hours 45 min

For this session I:
Session 8
• Worked with Johnny to test and improve the camera detection accuracy.
• Captured new training images for cards and worked on analyzing accuracy per card.
• Realized some cards were very blurry or misaligned and needed better cropping.
• Assisted Craig and Johnny in adjusting image capture timing to reduce wobble during photo taking.
• Started documenting and debugging mismatches between expected and detected card labels.
• Tested minor algorithm adjustments to improve detection fallback when accuracy is too low.
• Worked on implementing fallback detection strategy where camera shifts view slightly left if low confidence detected.
• Found a ton of screws from Johnny from ECE shop, ME Shop, ME Labs, ECE Labs, my research lab

Entry 4: -----------------------------------------------------------------

Date: April 23rd
Start Time: 9:30am
Duration: 3 hours 30 min

For this session I:
Session 8
• Helped align and test final assembly of the casing and electronics.
• Worked with Craig and Brendan to test system integration after installing magnets, brackets, and hinge components.
• Identified small mechanical misalignments and friction points at card feeder exit.
• Assisted Craig in retesting all slots and verifying that cards dispense cleanly.
• Participated in early computer vision tests where we found mislabeling of cards due to dataset ordering mismatch.
• Assisted with debugging and retesting after fixing the labeling order.

Entry 3: -----------------------------------------------------------------

Date: April 22nd
Start Time: 4pm
Duration: 3 hours

For this session I:
Session 8
Session 8
• Worked on wiring and testing the redesigned cable management system for the Pi and motor control PCBs.
• Tested initial integration of camera vision sync capture system with Craig and Brendan.
• Verified timing improvements for taking images exactly when feeder sensor triggers after card dispense.
• Helped retune feeder control parameters to reduce friction at gate for more reliable slot loading.
• Tested corrected vision pipeline and worked on checking captured images for crop correctness.

Entry 2: -----------------------------------------------------------------

Date: April 22nd
Start Time: 10:30am
Duration: 1 hour

For this session I:
Session 8
• Performed early day testing on camera setup and Pi Bluetooth stability.
• Assisted Craig and Brendan in testing control flow between camera, Pi, and STM32 MCU after small bug fixes.
• Helped retune Bluetooth pairing process to avoid manual user pairing by making slight tweaks to app communication method.
• Finalized LOGO Design and sent it to Johnny to laser cut.

Entry 1: -----------------------------------------------------------------

Date: April 21st
Start Time: 5pm
Duration: 2 hours 30 min

For this session I:
Session 8
• Worked with Brendan on setting up Raspberry Pi mounting and electronics housing.
• Helped tighten screws and perform small realignments after installing Raspberry Pi into the case.
• Soldered the capacitor on our backup PCB, had no issues.
• Helped test Bluetooth communication from Flutter app to Pi after setting up casing.
• Started debugging vision error where loose camera mounting caused accuracy drops.
• Helped test new adjusted camera mounting and rechecked calibration with newly captured images.
• Worked on early brainstorming for fallback strategies if camera accuracy was not enough for phone number game mode.

=============== Week 14: 20 hours 15 min (Cumulative 143 hours 30 min) =================

Entry 8: -----------------------------------------------------------------

Date: April 18th
Start Time: 1:30pm
Duration: 1 hour 15 min

For this session I:
• Firstly soldered the motor to wires
• Before we were using alligator clips which I did not like as they are not permanent
• I spent some time soldering all of them carefully, making sure to color code them to allow for easier use
• Again did not have any issues soldering. Could not find any heat shrinks, so will apply those later
Session 8
• Then I worked with Craig to work on the code to load and unload the cards at the same time
• I helped him hold things in place, track how many cards are getting loaded, timing etc.
• We noticed the cards were not getting dispensed right, came up with following ideas:
   • If we spin counter clockwise (card coming from up), shake it a bit once it reaches the exit destination as it can often get stuck
   • Continuously home the sensor even during dispensing, as it can run into some issues
• We were able to get timing of 3 min 30 second, for a task that a human took 3 minutes (which I simulated)
• Craig and I then discussed and confirmed we want to reach a time under 3 minutes for sure for Spark Challenge, and want to try get under 2 minutes
• We thought of some ways to speed it up but did not want to implement it right now.
Session 8
Session 8

Entry 7: -----------------------------------------------------------------

Date: April 17th
Start Time: 3:30pm
Duration: 2 hours

For this session, I:
Session 7
Session 7
• I first came in the lab and soldered male header pins on our backup PCB
• Soldered:
   • Multiple 4 pin male header pints
   • Multiple 3 pin male header pins
   • Multiple 2 pin male header pins
   • 1 pin male header pin
   • 24 pin female header pin
• Did not have any issues with soldering, just carefully went through each one
• This time I did male because Craig and Johnny mentioned that male header pins will allow us to declutter our PCB wiring a bit. I also agreed as after soldering, the pcb looked a lot cleaner
• After that, I retested the camera detection code, and it was still working great
• I cleaned up the code a bit and made it ready for the final version.
• Implemented the following:
   • Event-Driven Processing
      ◾ Previous: Continuous card detection (18-26 FPS)
      ◾ Now: Press 'c' to capture and process current frame
      ◾ Advantages:
         • Reduces CPU usage by ~80% (idle at 2% CPU vs 25% continuously)
         • Eliminates redundant processing when no cards are present
      ◾ This basically simulates the Pi integration code asking to read image
• I also cleaned up some functions, removed all the cv2.imshow calls etc.

Entry 6: -----------------------------------------------------------------

Date: April 16th
Start Time: 8pm
Duration: 2 hours 45 min

For this session,
Session 6
Session 6
• Firstly I worked with Johnny and Craig to test our power supply
• We were going from a 1 amp power supply to a 35 amp power supply with minimal current protection so we had to be very careful with our wiring
• We first just plugged in our wire and were happy to see the test LEDs turn on
• We then plugged in our ST Link and were able to successfully communicate with the STM
• We then tested our DC motors and stepper motors and they also worked perfectly which was great to see
• In fact their speeds increased due to the increased power which eventually allowed us to increase speed of dispensing
• We then tested our system, we spent some time recalibrating as we had increased power, but were eventually able to load up a deck of cards, which was great to see
• The increased power also ensured the cards were going all the way into the wheel
• After that, I worked with Johnny to integrate the new camera holder which would take the entire image of suit.
• After integrating that, I worked with Johhny to retake all the reference photos
• These were clearly better as previously the suit image was getting cut off, which I believe was partially causing the issue
• After that I started working on the camera code once again.
• I wrote a new file, implementing the following changes:
   • Detection Method
      ◾ Before: SIFT feature matching (scale-invariant but computationally heavy).
      ◾ Now: Template matching (normalized cross-correlation) with:
         • Pre-cropped templates (middle 1/3rd of card for robustness).
         • Rotated 180° to match camera orientation.
      ◾ Why it works better:
         • Faster on Raspberry Pi (no feature extraction overhead).
         • Less sensitive to minor rotations since templates are tightly cropped.
   • Region Splitting Logic
      ◾ Before: Fixed 40%/60% split (top for suit, bottom for rank).
      ◾ Now: Dynamic contour-based cropping within the split regions:
         • Finds card contour first → crops number/suit regions within the detected card.
         • It also now cuts left and right, making it more precise
         • Falls back to fixed split if contour detection fails.
      ◾ Why it helps:
         • Handles tilted cards better by aligning ROI to the card's actual bounds.
   • Color-Based Suit Filtering
      ◾ New: Uses HSV color space to classify suits as red (♥/♦) or black (♣/♠) before matching.
      ◾ Why it matters:
         • Reduces false matches (e.g., won't confuse ♥ with ♠ due to color mismatch).
         • Cuts template comparisons by 50% for suits.
   • Template Grouping
      ◾ Before: Flat lists for all cards.
      ◾ Now: Hierarchical groups:
         • number_groups: Templates grouped by rank (A, 2-10, J, Q, K).
         • suit_groups: Templates grouped by suit (hearts, diamonds, etc.).
      ◾ Why it's faster:
         • Only compares against relevant ranks/suits (e.g., "A" vs all Aces, not all 52 cards).
   • Confidence Thresholds
      ◾ Explicit thresholds: Requires both number and suit matches to exceed 0.7 confidence.
• These changes definitely worked better, but still the image was not getting detected all the times.
• With this code, I noticed some improvements and then iterated to the next code:
   • Structural Cleanup
      ◾ Before: Mixed card processing and display logic.
      ◾ Now: Clear separation into 4 phases:
      ◾ Better readability/maintainability for future changes.
   • More Efficient Template Storage
      ◾ Before: Stored full-color templates, converted to grayscale during matching.
      ◾ Now: Pre-converts to grayscale during template loading.
      ◾ 66% memory reduction (RGB → grayscale).
      ◾ Helped make frame rate much faster
   • Optimized Color Detection
      ◾ Before: Calculated pixel counts for red/black masks separately.
      ◾ Now: Uses cv2.countNonZero() directly on combined masks.
   • Simplified Matching Logic
      ◾ Before: Separate match_template() function with early continues.
      ◾ Now: Inline match_best() with unified score tracking.
      ◾ Helps Reduces function call overhead in tight loops.
   • Adjusted Confidence Thresholds
      ◾ Now: More lenient 0.4 threshold.
   • Optimized Color Detection
      ◾ Before: Multiple mask operations with temporary arrays
      ◾ Now: Single-pass HSV thresholding with direct counting
• All of these allowed my code to work PERFECTLY. The camera detection code was working correctly all the time! I tested about 30 cards and all of them worked great, even in lowlight.
Session 6
Session 6
• After that I headed home

Entry 5: -----------------------------------------------------------------

Date: April 16th
Start Time: 9:30am
Duration: 2 hours 45 min

For this session, I:
• First tested the code I wrote the day before
• Unfortunately, it did not work at all. I tried a bit of debugging but it would not work at all. It was not even detecting a single card with even 0.3 confidence.
• Wasn't very happy about that, but decided to try a different methodology.
• These were some of the changes I made in the next iteration of the code
   • Feature Detector Upgraded from ORB to SIFT
      ◾ Old: Used ORB (fast but less accurate for textured cards).
      ◾ New: Switched to SIFT (Scale-Invariant Feature Transform), which:
         • Better handles scale/rotation variations (critical for angled cards).
         • Extracts more distinctive features, improving matching accuracy.
   • Simplified Matching Pipeline
      ◾ Old: Combined edge similarity, grayscale correlation, and ORB keypoints (complex, prone to noise).
      ◾ New: Relies only on SIFT feature matching with a ratio test:
         • Uses knnMatch + Lowe's ratio test (0.75 threshold) to filter weak matches.
         • Score calculated as good_matches / max_keypoints, making it more interpretable.
   • Contour-Based Region of Interest (ROI) Extraction
      ◾ Old: Attempted full-image alignment (failed if contours were imperfect).
      ◾ New: Focuses on the largest contour (assumed to be the card):
         • Applies a mask to isolate the card region before feature extraction.
         • Skips alignment entirely, reducing computational overhead.
   • Reduced Image Resolution for Speed
      ◾ Old: Processed 640×480 frames (slower on Raspberry Pi).
      ◾ New: Downsized to 320×240 for faster SIFT computation without sacrificing accuracy.
   • Removed Redundant Preprocessing
      ◾ Old: Multiple edge thresholds, grayscale resizing, etc. (over-engineered).
      ◾ New: Only Gaussian blur + Canny edges for contour detection, then SIFT on the masked card region.
• Despite this attempt, this code also did not work.
• I then got an idea from the TAs to split the image in 2 and go from there
• I then worked on writing some new code for this implementation. Summary of changes
   • Split Detection Pipeline
      ◾ Old: Matched the entire card at once using SIFT features (prone to confusion between similar ranks/suits).
      ◾ New: Separates detection into two stages:
         • Top Half (Suit): Focuses on suit symbols (♥♦♣♠) using SIFT.
         • Bottom Half (Rank): Detects rank (A, 2-10, J, Q, K) independently.
   • Structured Reference Grouping
      ◾ Old: Single list of all 52 cards.
      ◾ New: References grouped by:
         • Suit (suit_references): 4 groups (Spades, Diamonds, Clubs, Hearts).
         • Rank (rank_references): 13 groups (Ace to King).
   • Dynamic Region of Interest (ROI) Splitting
      ◾ Old: Relied on contour detection, which could fail under occlusion.
      ◾ New: Hard-coded split at 2.5x height ratio (top 40% for suit, bottom 60% for rank).
   • Enhanced Debugging & Visualization
      ◾ New: Annotated displays showing:
         • Top/bottom halves with detected keypoints.
         • Real-time scores for suit/rank matches.
   • Score Normalization
      ◾ Old: Single score from whole-card matching.
      ◾ New: Combined score = (suit_score + rank_score) / 2.
• This code again did not work. I knew I was on the right approach, but something big was not working in the code as even though this was not able to detect cards, it was very wrong. It would be wrong half of the time, which made it very bad. It was progress but still very bad.
• Implemented another round of changes:
   • Enhanced Feature Grouping
      ◾ Before: Features stored in flat lists (reference_features_top/bottom) with redundant groupings.
      ◾ Now: Dedicated suit-specific (suit_references) and rank-specific (rank_references) feature banks.
   • Dynamic Score Thresholding
      ◾ Before: Fixed THRESHOLD = 0.5 for all matches.
      ◾ Now: Combined score derived from normalized suit/rank confidence ((suit_score + rank_score) / 2).
   • Debugging & Visualization
      ◾ Added Real-time keypoint visualization on split halves (top_half_display, bottom_half_display).
      ◾ Added Annotations showing suit/rank scores and detected symbols directly on the output frames.
   • Robust Error Handling
      ◾ Before: Silent failures if descriptors were missing (desc_top is None).
      ◾ Now: Explicit checks for minimal features (len(desc_top) < 2) and graceful fallbacks.
      ◾ Logs actionable warnings (e.g., "No features detected").
   • Optimized Camera Pipeline
      ◾ Before: Full 640x480 resolution with on-the-fly resizing.
      ◾ Now: Direct 320x240 capture + split processing.

Entry 4: -----------------------------------------------------------------

Date: April 15th
Start Time: 12pm
Duration: 2 hours 30 min

For this session, I
• I first worked with Johnny to assemble the new camera mount
Session 4
Session 4
• Once that was assembled, I used our code to go through all the images.
• I took 52 images, one for all the cards, methodically aligning all the cards by putting them into the slots
• As the card feeder was not plugged in, it took a while for us to take a photo of the cards.
• I then went home and started writing the camera recognition code.
• This is the basic logic of how the code worked
   • Initialization (__init__)
      ◾ Loads 52 reference card images (e.g., image_0.jpg to image_51.jpg) from a specified directory.
      ◾ Precomputes features (edges, grayscale, ORB keypoints) for each reference image to speed up matching.
   • Image Processing Pipeline:
      ◾ Preprocessing (_preprocess_image)
         • Converts to grayscale, applies Gaussian blur, and adaptive thresholding to isolate card edges.
      ◾ Contour Detection (_detect_card_contour)
         • Finds the largest quadrilateral contour (assumed to be the card) in the image.
      ◾ Perspective Alignment (_align_card)
         • Warps the detected card to a standard size (500×726 pixels) to normalize comparisons.
      ◾ Feature Extraction (_extract_features)
         • Generates multiple representations for robust matching:
            • Grayscale + resized image.
            • Canny edges (3 threshold levels).
            • ORB keypoints and descriptors (for structural matching).
      ◾ Matching Logic (_compare_images)
         • Combines three similarity metrics:
            • Edge similarity (template matching on Canny edges).
            • Grayscale similarity (normalized correlation).
            • ORB descriptor matches (count of matching keypoints).
         • Uses a weighted average (30% edges, 30% grayscale, 40% keypoints) for final score.
   • Real-Time Camera Integration (start_camera)
      ◾ Captures frames from Picamera2 at 640×480 resolution.
      ◾ Runs card identification at a configurable interval (default: 0.3s).
      ◾ Displays live feed and prints matches (e.g., "Found match: Ks (Score: 0.82)").
      ◾ Exit with q key.
   • Customization & Improvements:
      ◾ Card Naming: Supports custom card names (e.g., ["As", "2s", ...] for Ace of Spades, 2 of Spades, etc.).
      ◾ Threshold Tuning: Adjustable confidence threshold (match_threshold) to filter weak matches.
      ◾ Efficiency: Precomputes reference features to minimize latency during live matching.
   • Challenges & Solutions:
      ◾ Contour Detection: Handles imperfect card boundaries by approximating quadrilaterals.
      ◾ Lighting/Variability: Multiple edge thresholds and hybrid matching (edges + keypoints) improve robustness.
      ◾ Real-Time Performance: Feature precomputation and adjustable check intervals balance speed/accuracy.
• As I was at home, I was able to test the code only on the images and not on the live feed. I was getting 100% accuracy on the images, however as those were the reference points, it did not mean much. I left it till the next day to test the code.

Entry 3: -----------------------------------------------------------------

Date: April 14
Start Time: 4:45pm
Duration: 2 hours

For this session, I
• First went to go pick the O Rings from Cary Mailroom
Session 3
• Brought them back to the lab
• Johhny brought the new rollers and I spent a good amount of time putting the O rings on
Session 3 Session 3
Session 3 Session 3
• This honestly took a lot more time then expected as I would try different sizes which were often hard to put on and then johnny would need to put it in the feeder to see if it would fit
• Finally after a couple of iterations, we were able to fit the 6mm, 4mm and 4.5mm Orings, depending on the roller
• I had to be careful to ensure not to break them, and ensure they are all facing the right side up to ensure a smooth surface
• After testing, we were able to fit the o'rings onto the device and they fit great
• We then went to test the rollers
• I worked with Craig, Johnny to help dispense cards
• We tried a bunch of different speeds, durations, and directions of rotations of both the motors and were finally after a long time testing were able to get 52 cards to dispense.
• First we did have some minor issues, but were finally able to get it to work
Session 3
Session 3
Session 3
• This was the basic logic of the dispensing:
   • Both move back to align the card
   • Both move forward to dispense the card.
   • The back motor starts moving backward to catch the second card, while the first one continues moving to dispense the first card
   • Both move back to realign the card.
   • Found that the weight of a black electrical tape was a good weight, as something too heavy would make the end cards not get out, while something too light would cause too many cards to dispense at the end

Entry 2: -----------------------------------------------------------------

Date: April 13
Start Time: 1:45 pm
Duration: 2 hours 30 min

For this session, I

• First worked on soldering all the remaining components on the first PCB
• Soldered
   • 2 capacitors
   • 3 resistors
   • 1 LED
   • 1 Diode
   • Flywired a through hole capacitor
   • 24 pin female header pin
   • Multiple 4 pin female header pins
   • Multiple 3 pin female header pins
   • Multiple 2 pin female header pins
   • 1 pin female header pins
• Did not have many issues with soldering, soldered very carefully and slowly to ensure a strong connection and in close to 2 hours was able to solder everything
• Had a couple of minor issues:
   • Flywiring the through hole capacitor was hard as it was very delicate. Made sure to make the wire very long to ensure any pressure would bend the wire rather than put pressure on the hole
   • The 24 pin header pin required a lot of detailed look to ensure there was no shorted connection
Session 2 Session 2
Session 2 Session 2
Session 2 Session 2
Session 2 Session 2
Session 2
• After that, I wrote some code to test the camera and make it work
• I was successfully able to get a live feed from the camera.
Session 2 Session 2

Entry 1: -----------------------------------------------------------------

Date: April 12
Start Time: 3:15 pm
Duration: 4 hours 30 min

For this session:
  • Bluetooth Integration & Data Packaging
  • First we tried to integrate the Bluetooth code Brendan and I had worked on separately. Tested Bluetooth functionality; encountered issues with data packaging.
  • After some testing, I realized I cannot send a map of different elements via JSON. Changed data structure from a map to a list to resolve serialization problems.
  • Fixed oversized data packets ("too big" error). We continued to have issues with how big our packets were. We were capped to sending 182 bytes, and often times are packets would be 195 bytes, leading to error.
  • First I tried to send it as separate packets, implemented the code for that, but then we realized that on the backend side, knowing when packets are separate and when they are not will require an entire overhaul of code so I decided to find a new solution.
  • Addressed the 195-byte issue by modifying the send logic:
  • I completely overhauled and changed the logic to only send fields that are required.
  • Once this was implemented, still was running into issues for one game mode -> userSpecs.
  • Now for userSpecs we send 2 separate packets in same format, one with the specs, and one with the remaining configurations.
  • Now only sends data when userSpecs is called (on-demand).
  • Error Handling & Validation
  • Implemented checks to ensure a device is connected before executing operations for all game modes. Now you can’t click send if bluetooth device is disconnected.
  • Resolved negative ID issue in the winner/poker logic: We found out that sending a negative value was giving error, and once we found that out, I fixed it by setting that value to 0
  • I also wrote some code for the helper functions to automatically assign time or phone number when in custom screen depending on the game mode. Also made sure the formatting for the phone number is correct and can always be printed using cards.
  • Wrote a helper function (read()) to validate IDs.
  • Wrote a helper function to send data from Pi to app about who would win for random inform mode, and tested it -> Works
Session 2
  • Data Parsing Fixes
  • Fixed card-suit parsing (e.g., "heart" → h, "diamond" → d).
  • We had an issue that we could not pass the all the suit symbol from user specs and custom screen. However by changing into H, S, C, D made them very ugly
  • Wrote a mapping function which made sure to pass it as letters but show it as symbols
  • Changed code to match input for my algorithms to make sure the integration code does not need to do that.
  • Mapped algorithm values to their correct numerical prefixes (e.g., standardized input/output formats).
  • Team Work
  • Collaborated on a solution for hardware placement (O-rings issue).
  • I was very vocal on the current solution not working. I realized this will be a lot of extra work for Johnny, but I convinced the team that the rubber band solution will never work consistently, and this will end up saving time in the long term. The current rubber bands had a lot of friction and due to them not being flat, a lot of energy was wasted and hence the speed of dispensing was very slow
Session 2
Session 2
  • Reviewed youtube videos to explore alternatives
  • Looked at the following:
  • https://www.youtube.com/watch?v=eMTXyl7tPEk
  • https://www.youtube.com/watch?v=EKzgN_-8iP4
  • Found out that the O ring solution can work reliably
  • Finalized O-ring implementation.
  • Researched O rings on where to buy
  • https://www.amazon.com/QANYEGN-Roller-Cutting-Plotter-Recorder/dp/B0CDGVR7QB?th=1
  • https://www.amazon.com/dp/B0D8P255DB/ref=sspa_dk_detail_4?pd_rd_i=B0D8P255DB...
  • https://www.amazon.com/MECCANIXITY-Silicone-Rubber-Non-Slip-Wrapping/dp/B09WJFBCGY...
  • https://www.amazon.com/uxcell-Silicone-Flexible-Silicon-Transfer/dp/B07PPSYJK4...
  • Finalized: https://www.amazon.com/XBVV-Nitrile-Assortment-Plumbing-Connections/dp/B0CBTYXVCV...
  • This was finalized because it had a huge variety which meant we could try different sizes, it was black so would match our colors and had fast delivery.
  • We were running into some issues with airflow. Decided to relocate the power component to the right side of the device to improve airflow on the left.

=============== Week 13: 24 hours 15 min (Cumulative 122 Hours 15 min) =================

Entry 7: -----------------------------------------------------------------

Date: April 11th
Start Time: 2:15pm
Duration: 2 hours

For this session, I:

• Worked with Brendan to calibrate the Bluetooth messages so they match the Pi setup and the flutter side
• We agreed to the following JSON message, which was very different to what I had before:
Session 7
• Once setting these up, I now had to go through and change all my convert to Json functions for every mode.
• Firstly setup my sendGameSettings function
Session 7
• Wrote code for custom screen
Session 7
• Poker Select Screen
Session 7
• And all the other game modes including random, poker game mode, poker mods
• Verified the code is able to compile, but could not test as Brendan had to leave.
• Then I worked on trying to fix the capacitor that fell out.
• One of our capacitors broke and this lead to its pad getting detached.
• I talked to the TA (Shivam) and asked him for advice. I came to him with an idea of rather than using 2 decoupling capacitors in parallel summing 150 uF, using a 220 uF instead. For this now, rather than doing the same approach, I identified the reason it broke was due to the rigid wire in the capacitor, every time the capacitor was moved by someone, all the pressure would go onto the pad, leading into to break. I suggested that what if I connect a much more flexible wire to the pad and connect the capacitor to that, to ensure any pressure would be absorbed the flexible wire. He agreed that my idea made sense.
Session 7
• Firstly I removed the second capacitor that was still intact.
• This took a while as I was trying to be careful and there were a lot of components nearby, but eventually was able to take it off.
Session 7 Session 7
• As I was about to solder the new capacitor, I realized that now that the capacitor is off, it would make it much easier to solder the remaining components on the board, hence decided to wait till all those were soldered. As none of my team members were there then, I decided to not solder all of them as I could make a mistake.
• I then decided to fix one of the header pads that had broken. This actually took a surprisingly long time to take off. I did not want to use chip quick as there were a lot of components nearby. After some trying I was not able to take out both header pins at the same time. Then I decided to break them using a plyer so they were two separate header pins. This method allowed me to take them out in a couple of min.
• I then used some copper strips and the soldering iron to recreate the through hole big enough for the new header pins to go through
• I was able to do that and then eventually get the new header pins on.

Entry 6: -----------------------------------------------------------------

Date: April 10th
Start Time: 11pm
Duration: 1 hour 30 min

For this session, I:

• Focused on trying to figure out the camera detection for the Pi Camera
• First I aimed to find some already trained models and see if they can work well
Playing Cards Detection Repo
• Found this repo which made use of YoloV8.
• Once looking through the code, I found this dataset for trained cards: Playing Cards Dataset
• When looking through this, I realized this might be too heavy for the raspberry Pi to use as the dataset was over 2GB. This meant that I had to switch approach.
• I then tried to implement approach of using OpenCV functions to directly detect the app.
• Made use of following functions in step:
   • cvtColor
   • GaussianBlur
   • adaptiveThreshold
   • findContours
   • countorArea
   • boxPoints
• Did make use of some AI generated code as a starting point however did thoroughly go through the entire code to make sure it made sense.
• After trying for a while, it was not giving me good results, hence I decided to change my approach again.
• I thought of just taking a photo of every card, and then when I detect a card, differencing them from the 52 cards and finding the best match.
• I decided that this approach would be the fastest as it is the least computationally expensive
• Then I decided to write code for this
• I then implemented the code for this, using the following functions:
   • cvtColor
   • GaussianBlur
   • adaptiveThreshold
   • findContours
• I am unable to test the code right now as I don't have the images, but plan on taking the template images soon.

Entry 5: -----------------------------------------------------------------

Date: April 10th
Start Time: 3:00pm
Duration: 3 hours 30 min

For this session, I:

• We first worked on getting our 2 remaining checkoffs. This required a bit of work as we needed to rewire the breadboard to work for both. I assisted Brendan in Craig in doing some debugging, managing the Pi code and wiring up the STM to work correctly.
• We were successfully able to checkoff both, however, we needed to add some bootup sequences to the Pi to ensure it auto started UART.
Session 5
• Then we loaded all cards in the wheel and tested the servo motor. I aided in setting up the whole mechanism and holding the servo in place.
Session 5
• We were successfully able to load out cards.
• Craig, Johnny and I had a discussion about presorting vs post sorting. We all agreed that for non fast mode, presorting actually appears to now be faster due to not requiring to close and open the servo 52 times. However, I disagreed because for 10/12 game modes we could use fast mode, which would make post sorting much faster than presorting, not to mention all the code for presorting was already done. Based on this we decided to keep post sorting for now.
Session 5
• We then calibrated the homing sensor and connect it to the STM to encode the stepper to work accordingly. I helped Craig in finding the exact movements and tracking how much the stepper was moving in each step
• We also then calibrated the hold voltage for the stepper motor, by testing different ones out.
• We then also did some manual testing and found which speed appears to be best for rotating, and saved that in the system
• Lastly, we also then calibrated the minimum time delay between each step to ensure no skipping occurs
• Then Brendan and I starting working on integrating the Bluetooth code.
• Firstly, I made this BLE service
Session 5
• This contained the following functionality:
   • Setup start searching for devices
   • Setups up how to connect to the device
   • Sets up backend to disconnect from device
   • Sets up how to encode JSON message into BLE
Session 5
• Then in settings screen, setup functions for calling the BLE service.
• These basically made sure all the settings are correct to call these services, with some double error checking.
Session 5
• Next setup some backend to create a list of all devices and allow user to search for them.
Session 5
Session 5
• Once this screen was working, set it up to auto detect name "ECE477 Card Shuffler" and only allow the app to connect to that
• Eventually want to add some more robust error checking, but this can work well for now.
• We were able to get this to work, and send some dummy messages between the Flutter app and the Raspberry Pi

Entry 4: -----------------------------------------------------------------

Date: April 9th
Start Time: 8pm
Duration: 5 hours

For this session, I:

• Firstly I walked to Bechtel and back from the Lab to pick up some prints, I was free and Johnny was working so I volunteered to do so
Session 4
• I picked up the prints but they were very damaged
• I spent some time in bechtel cleaning up the sides (looked like a pine cone before), and was able to get it to this, but they were still too damaged to use
• Johnny agreed we could not use them
• We first were trying to figure out how to get the DC motors to work and why they were not working. We put the chip in the slot without soldering it to test. However the motors would not move. We were able to use the multimeter to confirm they were getting powered. Then I offered to solder it to make sure it was getting good contact.
• I then soldered the DC motor IC to power them
Session 4
• Was able to do it without any issues, soldered two corners and carefully soldered each pin
• We started getting a very weird error that the 3.3v led was powering the 5v led. We checked every lead under a microscope, checked the code many times, made sure 5v was not getting powered, but could not figure it out. We thought potentially there was a connection between GPIO and the heartbeat LED but I was sure there was not.
Session 4
• The only other explanation was that there was potential jumping occurring.
• Johnny felt strongly that there could be a solder connection that we are not seeing so I offered to solder it again.
• As I was about to start, Craig and I thought that there has to be some other issue, because that made absolutely no sense.
• We then thought of the potential that the PCB never has to work on only 3.3V, so as long as when 5v is powered, the LED gets 5v, it shows it works
• We then attached the 5v power and like we thought it was working, and the multimeter showed 5v at the LED. We then concluded that it was probably jumping when 3.3v was enabled and 5v was not, however, as practically that would never happen, we let it be, as when 5v was connected, it was getting 5v.
Session 4
• We were finally able to get the Motors to work and were very ecstatic
Session 4
• I then aimed to solder the capacitors and the USB C port
• However this is where we ran into issues. When I was soldering the USB C port, we thought of potentially using solder paste, however due to my experience with soldering iron, I thought using a soldering iron would work best.
• I was able to successfully attach the 4 pads with ease.
• When trying to solder the tiny 5 pads, I soldered 3 of them perfectly, and someone then pin 2 and 3 got a short, as I accidentally put too much solder. I used the standard techniques of trying to move the solder, adding more flux, using copper wires, etc, but none would work.
• Somehow the solder then got under the USBC port
• This meant that I was not able to get to it without and heat it up. I tried for 45 minutes with all these approaches but none worked.
• Then I agreed to remove it, but due to the solder being under the pad, I could not remove it.
• I then decided to use chip quick and a heat gun. I applied the CHip Quick and added more solder. Then using a heat gun and Johnny's help, I was able to remove the USB C chip.
• However, in doing so, one of the pads came out.
• We then checked the PCB and it was a ground pad, and hence got lucky that it did no damage. Then Brendan offered to resolder the USBC port and I agreed as I had just made the mistake. I sat beside him and offered him any help when necessary, and were able to successfully attach it.
• I then soldered the stepper motor driver, 3 capacitors, 4 header pins and 2 resistors. Was able to do these carefully without any issues.
• I then attached the 2 capacitors successfully by fly wiring them. I did not run into any issues but realized I needed to be super careful. I carefully was able to attach them, but told the entire team to be super careful.
Session 4
Session 4
• After that, Craig and I worked on trying to get the stepper motors to work, and we were successfully able to do so.
Session 4
• After that, we called it a night

Entry 3: -----------------------------------------------------------------

Date: April 9th
Start Time: 9:10am
Duration: 4 hours

For this session, I:

• I first went to Bechtel to pick up some prints Johnny asked me to pick up. I also made sure to carefully remove all the support material, to ensure no piece is damaged
Session 3
• I then setup the Raspberry Pi to connect to the monitor to test some code to get some images from the camera
Session 3
Session 3
Raspberry Pi Camera Guide
• Looked at this article to see how to configure the camera, however after some testing, found out it automatically configured
• Tried configuring using raspi-config
• Wrote this script to capture some images
Session 3
• Used it to connect to get some reference images like this:
Session 3
Session 3
• Connected the light source as well, to test for glare
• We then tested the card feeder and it was finally able to dispense cards at a great pace, this was because the new motors had arrived which had 1000 RPM
• It showed the system could work
Session 3
• We then tried to flash the STM but it was not working. After some debugging we found out the diodes seem to be the issue, by seeing no voltage was going across it.
• I then desoldered the diodes, and put a small wire across it
Session 3
Session 3
• We then were able to get the LED lights to turn on, indicating power was working
Session 3
• We then were able to flash the STM succesfully

Entry 2: -----------------------------------------------------------------

Date: April 8th
Start Time: 12pm
Duration: 4 hours

For this session, I:

• As the water had dried, I wanted to check the STM once again
• I noticed some pins weren't correctly soldered
• I spent some time fixing those and made sure there were no shorts
Session 2
• Once I had done that, I spent some time soldering a bunch of components
• Soldered 8 Capacitors
• 1 button
• 4 header pins
• 2 diodes - Had some issues because pads were very tiny, but was able to get them to work
Session 2
Session 2
Session 2
Session 2
Session 2
• Did not have many major issues soldering it, followed the tutorials I watched the day before, and went carefully about soldering them
• For one of them, I put too much solder, so used copper strips to remove it
• Once all of these components were soldered, I looked through them again under microscope
• Cleaned them using distilled water and compressed air
• Checked again under Microscope
• I then used a multimeter to check for any shorts in the STM, but did not find any
Session 2
• Went to ECE shop to have them check my STM
As it was clearly visible, Ryan just checked under a microscope and confirmed all my connections looked good
• I then spent some time researching how to use connect Bluetooth to flutter app
• Looked at this article: BLE with Flutter
• Understood some of the basic setup i need to do
• Looked at the following library: Flutter Blue Plus - Finalized this one due to ease of use
• Used some AI tools to walk me through some steps on how I should go about it (not code, just what are the steps and what dependencies i need to edit)
• Got tired so decided to leave it for the next day
Session 2

Entry 1: -----------------------------------------------------------------

Date: April 7th
Start Time: 3pm
Duration: 3 hours 45 min

For this session, I:

• Watched the following tutorials on soldering, to make sure I know all details once more
Soldering Tutorial 1
• Learned how to make setup to align solder paste using stencil
• Learned how to use solder paste
Soldering Tutorial 2
• Learned important principles about SMD soldering
• Learned how to solder SMD diodes and capacitor (apply solder to one side, slide component in place and solder other side)
• Learned ideal temperature of solder and which tips to use
• Learned how to use tweezers for smd soldering
• How to fix mistakes of adding too much solder
• Learned how to apply SMD components with multiple pins
• Learned how to solder SMD IC chips (two sided)
• Learned some tips on soldering IC chips (4 sided)
• Learned how to align SMD capacitors
• Learned how to solder USB C port onto PCB
Soldering Tutorial 3
• Gained some more insight on how to best solder IC chips
• Learned technique of fixing 2 opposite corners and then soldering everything else
• Practiced soldering microcontroller one more time
• Applied these skills to successfully solder a MC perfectly
Session 1
• Finally decided to solder the real one
• First aligned the first pin of STM with PCB
• Used this datasheet: STM32 Datasheet
• Verified multiple times
• Soldered 2 pins on opposite ends
• Use fine tip solder to solder all pins, with plenty of flux
• Surprisingly had almost no issues, and soldered perfectly
Session 1
• Thoroughly checked all sides, and showed it being perfect
Session 1Session 1
Session 1Session 1
• Thoroughly cleaned it using distilled water and pressurized air
• Checked again under microscope, looked very clean
• Tried to go to ECE Shop but was closed
• Johnny then brought the wheel to lab, however, it had a lot of powder in it
• I spent about 45 minutes using a playing card to keep on trying to fit them in each hole, and alternating with pressurized air, to allow the powder to escape. I would basically insert the card, make the powder lose, and then use pressurized air to remove it. I did multiples times for each slot, and then repeated the entire process again.
• The cards would insert very easily in pretty much all slots after this
Session 1
• I then also wanted to make a testbase for using solder paste and hot plate, so using the stencil, I made the below piece to make the PCB perfectly aligned with the holes, and made it so it cannot move.
Session 1
Session 1
• Then, I needed to find the correct power pin for the PCB
• It was very hard to find as there very many male ATX power pins, but very few female ones available
• Looked at these:
   • Power Pin Option 1
   • Power Pin Option 2
   • Power Pin Option 3
   • Power Pin Option 4
• Also looked at this for advice: Power Pin Advice
• Finally finalized this one: Final Power Pin Choice
• This was best because Digi Key is reliable
• Molex is a reliable manufacturer
• Its datasheet had the exact dimensions which matched the PCB
• Though it is white and might look a bit odd, as this was the only one that had exact dimensions on its datasheet, it made more sense to pick this one.

=============== Week 12: 10 Hours (Cumulative 98 hours) =================

Entry 3: -----------------------------------------------------------------

Date: April 4th
Start Time: 1pm
Duration: 3 hours

For this session, I:

• Set up the Bluetooth app to firstly create a simple data structure to store all data, convert it to json, and send to app (still yet to complete fully)
• I first had to make some design decisions on how to store data
• First thought that maybe make separate data structure for each game mode
• Implemented for random screen, poker screen
• Realized half way through, that this is pretty inefficient as having different json structures will make it much harder to manage data on Pi. Furthermore, it really complicates the code and leaves it open to human errors as have to track 8-10 different data structures.
• Restarted and created following format
Session 3
• Used this as I can save mode, dump all data specific to game mode in a list, and simply pass it as that
• I can also save the user preferences to make sure I pass them everytime
• Using this method, I can easily check mode on Pi and based on the specific mode, correctly assign and choose data in the data list
• Created Game Settings Class to save this data
Session 3
• Created GameSettingManager Class to populate data
Session 3
• This ensures we have a manager to make sure all data is populated
• Makes it much easier to separate functions if two different classes
Session 3
• Created individual functions for all games modes to populate data in GameSettings
• Created Snack Bars little popups to show that we have initialized it as well

Entry 2: -----------------------------------------------------------------

Date: April 3rd
Start Time: 6pm
Duration: 3 hours

For this session, I:
Session 3 Session 3 Session 3
• Firstly spent some time researching on how I can make a good logo
Logo Design Tutorial
• Watched the video
• Learned importance of clean design
• Importance of using color wheel in correct format
• How to manage symmetry in a logo
• Impact on font etc.
• Came up with a basic list of ideas on what I want
   • Not too colorful
   • Simple design
   • Want to show a couple of cards (probably 3 aces signifying amazing cards)
   • Want to show some sort of machine
   • Don't want app to seem like a cheat from the start
   • Give appeal of very techy
• Used a bunch of softwares to try make logos
   • Chat GPT
   • Canva
   • Adobe
• After testing out, found canva to be closest to what i want
• Iterated through 40 logos in Canva, to reach to this logo
Session 3
• Approved by 2 team members, waiting for one feedback, but pretty confident this is going to be logo
• Then, I wanted to allow the flutter app to save data on device
Flutter Data Storage Tutorial 1
Flutter Data Storage Tutorial 2
• Watched both tutorials
• One used shared_preferences, one used HIVE
• Learned HIVE is much more useful for trying to save larger files, ensuring data safety, and high performance
• Shared_preferences is better for simple user preferences, which can be saved using strings and ints.
• As I am only saving phone number and a couple of user preferences, picked shared_preferences
Session 3
• Small screenshot of part of the code

Entry 1: -----------------------------------------------------------------

Date: April 2nd
Start Time: 9:30am
Duration: 4 hours

For this session I:
Session 3
• First as a team, we discussed if we should use shafts or a 3d printed shaft
• Johnny mentioned 3d printed is easier
• I thought a metal shaft would provide more support
• I researched multiple shafts
   • McMaster-Carr Shaft 1
   • McMaster-Carr Shaft 2
   • McMaster-Carr Shaft 3
• After discussing as a team, and prof feedback, we just felt it was much easier to 3d print them
• I then went to ECE Shop to get some components: assortment of header pins and sockets
Session 3
• I then worked with Johnny to test the card dispenser
• It was working finally, however, it is still nto dispensing with the accuracy and speed we need
• We came up with a list of things we needed to address
   • Need rollers to be in exact position, explore bearings
   • Need to add more rubberbands due to some minor issues with gripping
   • 2nd roller should be closer to make sure cards are shot out
   • Higher RPM motor to increase speed
   • Build casing to hold motors
Session 3
Session 3
• We then discussed how can we solve the servo motor issue
• We all came up with a bunch of ideas, but finalized one that I came up with. Idea was basically to change shape of cover for cards, and allow something to turn that will go exactly flush with cards to make sure it does not fall out
• Image: Session 3
• Based on this, researched different motors
   • Motor Option 1
   • Motor Option 2
   • Motor Option 3
   • Motor Option 4
   • Motor Option 5
• Looked at all of these, and picked the Greartisan one. This was because of many more reviews, already used motor from this brand and it works, and an RPM that fits our exact requirement
• Brendan notified me that we cannot use the current capacitors in our PCB. Based on this, I spent a long time researching different types of capacitors. Shortlisted 7, of ceramic and electrolytic. Researched differences and consulted TAs and concluded both can work for our requirements.
• Capacitor Research
   • Capacitor Option 1
   • Capacitor Option 2
   • Capacitor Option 3
   • Capacitor Option 4
   • Capacitor Option 5
   • Capacitor Option 6
   • Capacitor Option 7
   • Capacitor Option 8
• Johnny and I started at the procurement office, but they redirected us to the BHEE building manager. He then pointed us toward the ECE shop. What followed was a frustrating loop of being sent from one place to another with no clear resolution. After several rounds of this, we were finally able to persuade the procurement office to place a new order for our parts. The original shipment had already been delayed for three weeks and had seemingly gone missing—either somewhere at Purdue or in transit with DigiKey.
• Johnny and I then went to ME Shop to get an assortment of pieces. After going around a bunch of rooms to acquire all our parts, we were able to get all the pieces we need. Bearings, couples and mores
• I then practiced my soldering skills again, and resolder a microcontroller to a PCB. It took me a while to align the MC but after it was aligned, my work was a lot better than before. While it was not perfect, it was much better than before.

=============== Week 11: =================

Entry 5: -----------------------------------------------------------------

Date: March 28th
Start Time: 4:30pm
Duration: 1.5 hours

For this session, I:

• Completed A9 to completion
• Please refer to BrightSpace and project website for full details

Entry 4: -----------------------------------------------------------------

Date: March 28th
Start Time: 1:30pm
Duration: 1.5 hours

For this session, I:
Session 3 Session 3 Session 3
• Made some improvements to the flutter app
• Added error checking to ensure for all screens
• Implemented check that for user select screen, it makes sure all cards are different, if they are not, throws a popup message
• Implemented using Flutter
• Uses showDialog function to create pop up
• Create a list of all cards. If that card is already in the list, then it means there are duplicates
• Implemented error checking for phone number
• Checks if a digit is repeated more than 4 times, if it is, cannot use cards to display it
• Used RegExp to get only digits
• Creates map of all digits, if any have occurrences more than 5, then return cannot save
• Implemented using Flutter
• Uses showDialog function to create pop up

Entry 3: -----------------------------------------------------------------

Date: March 27th
Start Time: 5:30pm
Duration: 2 hours

For this session, I:
Session 3 Session 3 Session 3 Session 3 Session 3
• Attended the soldering workshop
• Learned how to solder a microcontroller onto PCB
• Learned how to desolder a microcontroller
• Learned the following steps:
   • Apply resin to one edge
   • Apply solder to same edge
   • Align microcontroller
   • Apply solder heat to fix it
   • Apply resin to all other edges
   • Apply solder and use drag soldering to solder
   • Come back to original edge and solder again if less solder was applied
   • Use distilled water and pressurized air to remove resin
   • Let it sit for overnight / 24 hours
   • Look under microscope to check for short circuits
   • Use multimeter to check for short circuits
• Personally:
   • Soldered 2 microcontrollers onto test PCBs
   • Had some difficulty due to not having flat edge for drag soldering, but achieved good results after the first try (1-2 shorts)
   • Desoldered one microcontroller using Vacuum Desoldering station, did end up bending some pins, but microcontroller came of successfully

Entry 2: -----------------------------------------------------------------

Date: March 26th
Start Time: 9:30am
Duration: 2 hours

For this session, I:
Session 3 Session 3 Session 3 Session 3
• Researched components to order, these are some parts that were yet to be ordered for our PCB
   • Molex Connector
      • This was selected as DigiKey has fast shipping times
      • Molex is a very reliable manufacturer
      • Verified with datasheets dimensions fit our PCB Board
   • Molex Header
      • This was selected as DigiKey has fast shipping times
      • Molex is a very reliable manufacturer
      • Verified with datasheets dimensions fit our PCB Board
      • Many in stock so will not have major issues on delays
   • Dialight LED
      • This was selected as DigiKey has fast shipping times
      • Verified with datasheets dimensions fit our PCB Board
      • Many in stock so will not have major issues on delays
• Found some alternatives for these on Amazon as well, however, these had better reliability, faster delivery time, and better customer support, along with reliable datasheets hence these were selected
• Assembled new camera with new cable to Raspberry Pi
• Spent time researching for A9 - took some following notes
   • Looked into the following regulations:
      • FCC
      • CE
      • UL
      • IEC Certification
      • ROHS
   • State wise casino rules
      • Did not find formal rulings
      • Looked into Gaming Laboratories International (GLI), found some formal definitions for what a card shuffle is

Entry 1: -----------------------------------------------------------------

Date: March 25th
Start Time: 3:45pm
Duration: 45 min

For this session, I:
Session 3
• Individually talked with Johnny, Craig and Brendan and discussed plan for the rest of the semester
• Set some guidelines to "grind" out a lot of the work by end of week 12
• Inspected the new PCBs to make sure there are no major issues
• Placed pieces on the PCB to make sure everything appears to fit

=============== Week 10: =================

Entry 1: -----------------------------------------------------------------

Date: Spring Break
Start Time: N/A
Duration: 0 hours

For this session, I:

• Spring break, no work conducted

=============== Week 9: =================

Entry 3: -----------------------------------------------------------------

Date: March 12th
Start Time: 9:30am
Duration: 2 hours

For this session, I:

• Met with team and showed the app
• Got some feedback:
   • Change icon to make it more fun
   • Add specific settings which are bool in settings screen to make preset options:
      • Burn Cards
      • Rotate Dealers
      • Is fast mode
      • This mode will not shuffle irrelevant cards and output them in fast mode
• Implemented all feedback during MAN Lab
• Presented working app to Professor
• Worked with Brendan to come up with JSON datatypes for app BLE transfer
Session 5 Session 5

Entry 2: -----------------------------------------------------------------

Date: March 9th
Start Time: 10am
Duration: 9 hours

For this session, I:

Session 5 Session 5 Session 5 Session 5 Session 5 Session 5 Session 5 • Coded approximately 1800 lines of code (some repetition) to make my entire app
• All design decisions were pretty much made and explained beforehand, see previous journals for Figma designs for more details
• Replicated Figma designs to a very high accuracy
• Highlighting some of the new additions:
   • Making user select screen such that it is split in two
      • Reason is by having number of players option in first part, based on that I can refresh the second screen, so it dynamically increases number of players and is very easy to follow
      • If it was all in one screen, dynamically adjusting the current screen can run into bunch of errors
   • Force set portrait mode
      • Makes it much easier to solve any formatting issues
      • Landscape was pretty useless for app design
   • Made simple screen for “Random” Poker Shuffle
   • For specific mods like unwinnable winner, only allows to select player if that mode is selected
      • Helps improve UI
   • For specific custom modes like bring card on top, only allows to select card if that mode is selected
      • Helps improve UI
   • Made basic settings screen, more work done on it later in the week

Entry 1: -----------------------------------------------------------------

Date: March 8th
Start Time: 4pm
Duration: 2 hours 30 min

For this session, I:
Session 5
• Worked on setting up Flutter on Mac
• Downloaded Xcode
• Ran into multiple issues
   • Tried 3-4 times, 8GB download each time, but could not resolve
• Signed up for developer account
• Downloaded DMG through Apple website
   • Worked
• Downloaded Flutter
• Setup in VSCode
• Downloaded Simulators
• Attempted running after entire setup, but did not work due to low battery and RAM in my device
• Decided to rather test on my own iPhone instead
   • Slightly more risky, but will resolve this issue
• Put phone to developer mode
• Enabled developer settings through Runner App and Xcode
• Was able to have dummy app working on phone
• Followed following tutorials:
   • Flutter Install Guide
   • Direct Download Xcode
   • Test Flutter App on Real Device

=============== Week 8: =================

Entry 5: -----------------------------------------------------------------

Date: March 7th
Start Time: 8:15am
Duration: 2 hours 15 min

For this session, I:

• Met at 8:15 to do one full run through of presentation
• Made some minor changes as we discussed
• Conducted mid-term design review presentation at 9:30am for our team
• Got following feedback:
Session 5

Entry 4: -----------------------------------------------------------------

Date: March 6th
Start Time: 4:30pm
Duration: 1.5 hours

For this session, I:

• Sat together as a team and detailedly walked through each slide of presentation, practicing each part
• Assigned the following tasks for all of us:
   • @craig put stepper motor driver, use case
   • @craig put use case for power supply
   • @krish add image of printed wheel
   • @Hazboun update card dispenser file
   • @krish add pic of mechanical components
   • @brendan add pic for low level
   • @craig record video of stepper motor
   • @craig take video of servo
   • @krish photo of card dispenser
   • @craig add legend for software dev status
• Took some photos of our setup for midterm design review
• Had a practice run through for specific sections

Entry 3: -----------------------------------------------------------------

Date: March 5th
Start Time: 10:30am
Duration: 3 hours 30 min

Session 5 Session 5 For this session, I:

• Created this Gantt Chart
Session 5 • Discussed current progress with team, assigned these for everyone:
   • @everyone Goals by Tomorrow 3:30pm (Try if you can do all this)
      • Upload all your documents onto the website, all the group ones, I can do, make sure to upload your individual ones
      • Look through your slides once again (except PCB and schematic) and polish it up, the ones I did, might not be completely done
      • Practice your slides
   • @Hazboun try finish the PCB, I know it is a lot, so do your best
   • Tasks for tomorrow meeting:
      • 4:30pm we do one quick run through
      • Upload all schematic and PCB photos
      • Practice PCB parts
      • @craig @krish record stepper motor and card dispenser videos
      • Look through slides once more
• Came up with list of potential heartbeat LED possible locations for testing purposes:
   • LED from homing to microcontroller
   • Microcontroller power
   • Enable for Stepper
   • Enable for DC Motor
   • Extra one connected to extra GPIO pin for debugging purposes
• Found this camera:
   • Aokin Raspberry Pi Camera
   • Reasoning:
      • 5 Megapixel Camera
      • Adjustable Focus Lens
      • Capable of 1080p 30 fps
      • Automatic IR-CUT Camera (Night Vision)
   • Alternatives considered:
      • Raspberry Pi Camera 3 (Too expensive)
      • Innomaker Raspberry Pi Camera Module (Worse reviews)
      • Raspberry Pi Camera Module 3 Wide (Expensive)
• Found this camera cable:
   • A1 FFCs Camera Cable
• Found this LED for lighting:
   • Chanzon High-Power LED
   • Bright and powerful
   • 5v
• Spent time improving overall Midterm design review presentations

Entry 2: -----------------------------------------------------------------

Date: March 5th
Start Time: 9:30am
Duration: 1 hour

For this session, I:

• Attended 1-hour presentation as part of Midterm design review

Entry 1: -----------------------------------------------------------------

Date: March 4th
Start Time: 4:30pm
Duration: 1 hour

For this session, I:

• Attended 1-hour presentation as part of Midterm design review

=============== Week 7: =================

Entry 5: -----------------------------------------------------------------

Date: Feb 28th
Start Time: 1pm
Duration: 1 hour 30 min

For this session, I:
Session 5 Session 5 Session 5 Session 5
• Worked on adding more slides to the Midterm design review presentation
• Approx added 35 slides to our presentation, while these are not all complete, set up the entire structure, so Johnny and brendan just need to past pictures into it
• Split up all Packaging Design Slides and noted the photos we need
• Split up all Schematic Design Slides and noted the photos we need
• Split up all PCB Slides and photos we need
• Made some designs for Progress slides to make it easier to understand
• Finished all High Level Software Progress Slides
• Split up all Current Progress Slides and noted the photos we need
• All photos are noted as the slide title itself

Entry 4: -----------------------------------------------------------------

Date: Feb 27th
Start Time: 5:30pm
Duration: 1 hour 15 min

For this session, I:
Session 4 Session 4 Session 4
• Once we had the rubber bands, I attached them to the spinning cylinder, and then Johnny and I, attempted to test the mechanism
• It worked, while it did need some improvements, it fit well, appeared to have enough friction, etc.
• However, our design needed some improvements for the card dispenser
• I talked to Johnny and suggested the idea of adding grooves on the cylinder to make the rubber band fit snuggly, and adding extra space where the cylinder sits for the rubber bands as well.
• He agreed with this design decision and began designing it
• While he designed it himself in Fusion, I helped in the process getting dimensions, helping him fix errors he was running into, and give some fusion tips to create the changes
• Afterwards, we sat down as the entire team so we can all go through the KiCAD design to make sure everything is okay. There were several things we noticed. These are some changes I personally noticed and helped Johnny and Brendan fix:
   • Diode voltage drop at power -> Check if there is any voltage drop
   • Allow motors to go in both directions -> Adding H bridge functionality
   • Recommended making one go in both so we do have one which is guaranteed to work in case of any errors
   • PWM on enable -> Adding this signal so that we can control the speed of the motors, rather than having a GPIO pin, which will just turn it on and off
   • Made sure to make sure no PWM for stepper motor should work
   • Helped fix power coming into DC Motor H Bridge (was 12,12), should have been (5v, 12)
• I also suggested adding diodes for power protection after splitting off the 3.3v to its different destinations. This is because, while the power supply would be protected with the diode at the source, a power surge could travel from one component to the other, which could cause damage. Brendan and Johnny said they would check if they can implement it, but thought it was a good suggestion

Entry 3: -----------------------------------------------------------------

Date: Feb 27th
Start Time: 12pm
Duration: 45 min

For this session, I:
Session 3
• I checked my mail but it appeared someone stole the rubber bands I ordered
• While it was annoying, I was not going to fight Walmart for a very small item value
• I then decided to find it in person because I felt we really needed to make progress on the dispenser and waiting one more week would be pretty counter intuitive
• I then walked all the way to the university bookstore, but could not find any small rubber bands, they only had big ones
• I then checked Vons, but they were out of stock for small bands
• I then went to target, and bought them again with my own money, and then brought them to lab

Entry 2: -----------------------------------------------------------------

Date: Feb 27th
Start Time: 12pm
Duration: 2 hours

For this session, I:

• Worked on starting work on the PPT Slides
• Created the following slides. Have attached some images above as well, but this covers all the progress:
• Note: All these slides are done to completion and pretty much finalized
   • Title Slide
   • Meet our Team
   • Presentation Agenda - 3 Slides
   • Project Overview and wrote description
   • PSDRs
   • Major Component Analysis Slides - 10 Slides
   • Wrote descriptions for STM, Pi, Stepper Motor and Power Supply
   • Added relevant images
   • Created design decision tables
   • Added data tables for info
Session 2 Session 2 Session 2 Session 2 Session 2 Session 2 Session 2

Entry 1: -----------------------------------------------------------------

Date: Feb 26th
Start Time: 9:30am
Duration: 3 hours

For this session, I:
Session 1 Session 1 Session 1 Session 1 Session 1
• Firstly I presented all the software progress to the team
• We then had our one on one with the TAs and Professors and presented our progress
• I then worked with Johnny to try and get the card dispensing mechanism to work
• We first tried the rubber bands I brought, but we noticed they are too thick and would need to be glued to the spinning cylinder. This could cause issues as gluing it would make it permanent
• I then came up with the idea to go the WALC Knowledge center as they have a lot of art and craft material
• Once we got there, we acquired some rubber bands, different kinds of tape, and some fuzzy metal strips
• We brought all of them back but they did not work for the following reasons:
   • Rubber bands: Too big so would need to be glued
   • Tape: Not enough friction
   • Fuzzy Metal Strips: Too thick, so don’t fit in the device
• While we could make adjustments to the device, I thought that we should get something that would work more reliably
• Then I came up with the idea to get small rubber bands
• I found these:
   • Walmart Rubber Bands
• As the delivery time for Amazon was long, I just decided to buy them with my own money and got them delivered to my home
• I then started reviewing the documents for the Midterm design review
• I read the entire document, and looked through the example slides, and found that we should make sure to have the following:
   • Minimal font
   • Maximum focus on schematic
   • Easy transition slides to make clear
   • Datasheets and data tables
   • Design Decisions etc
• I then started looking for different templates:
   • Slidesgo
   • SlidesCarnival
   • SlidesMania
• Finalized this one as it was professional yet had some character and was visually appealing: Human Thermoregulation Template
• I then also added some slides to breakup our sections into the following (11 slides):
   • Project Overview
   • Major Components
   • Block Diagram
   • Packaging Design
   • Schematic
   • PCB Layout
   • Prototyping Progress
   • Software Development Status
   • Project Timeline
   • Q/A
   • Thank you

=============== Week 6: =================

Entry 5: -----------------------------------------------------------------

Date: February 20th
Start Time: 5:30 PM
Duration: 1 Hour 30 Minutes

For this session, I:
Session 4 Session 4
- Spent about 30 minutes trying to desolder header pins from Raspberry Pi.
- Watched these tutorials as reference:
   • Tutorial 1
   • Tutorial 2
   • Tutorial 3
   • Tutorial 4
- Learned the following concepts:
   • How to use copper wires to remove solder.
   • How to clamp PCBs to allow easy access to pull out header pins.
   • At what angle and what kind of soldering iron tip to use to desolder header pins
   • Which solder suckers to use and how to use them to remove solder
   • How we can add more solder to remove it all at once
   • Adding flux to specific solder points to make removing solder easier
   • What temperature to use to remove header pins
   • WSome more tips surrounding this topic
- However, I did not make much progress.    •While I did try all the tricks, the solder would not come out
   •While less solder was there, there was still some solder
- Considered using a desoldering gun but sought advice from TA first.
- He said this would be nearly impossible
- This is because I need to remove all 48 pints from Raspberry Pi at once, which can only be done with a hot plate
- However, this would make other components get loose and potentially short circuit
- Asked him about using desoldering gun
- Asked him about using soldering paste on header pins to reduce temperature point
- He said while you can try, 90% it will likely end up killing your board
- Helped us get another solution on either adding a fan to solve heating issue or using small ribbon cables by having male header pins on PCB
- Then we decided to test the new motors, but realized they were too slow
- I thought about using some drone motors available in Lab, however, we felt that this would make it overly complex, as would require new power functionality
- I then came up with idea of using gears
- By using 3:1 gear ratio, we could convert 200 RPM to 600 RPM
- Found this gear set: https://www.amazon.com/Differential-Metal-Motor-Redcat-Monster/dp/B0881RWD2L/ref=sr_1_9?crid=DYN641CL4WZU&dib=eyJ2IjoiMSJ9.G9L8pAf-U0D_PKFd5XfkI4SFW6BNDhYxDCVnevDI4k_F7IITbg-N8H50cmDBADEPOQY1bbwha4hLPSkbU9UD9-nxKNCNPCO5diqIbRhArDrriMitX1OqYGFSfsrUxdj2WGACXtrm6Bn_HsKFDMe2tpm_VodvW9ksn9pH2x8mejyiOVNy-BVa6vgFVZdXdoJCyUmnl45q1RgJs4NwN9ltVKSvu_WNIkg2Oh5oLhqg2fEqkEFuNsAIZsv3ij_9hUq4y658p7t3f3c6VkNXVgGmQKznP4e2x_YgYeftfO6AHY6vppmKQ9abIeun2kzJG7tx587QtphieFvNqg0vE6UtBBtTZYOxorFvgorkpBXXpE6RLTAH56VIuUVtdsoUHaAqouLm2v4fRNT1Ue0tdkyybja3bYgvWKLZafigWF8hkHMS_LP8a65T4Zw41NRFWHxi.A8qm2Sz0gg4m3uuz5qAb3kds_RF0sd2kVTS_EiJQOmk&dib_tag=se&keywords=metal+gears+set+3%3A1&qid=1740098048&sprefix=metal+gears+set+3+1%2Caps%2C123&sr=8-9
- Asked Johnny to order it

Entry 4: -----------------------------------------------------------------

Date: February 20th
Start Time: 12:00 PM
Duration: 30 Minutes

For this session, I:
Session 4 - We received the new motors for our card dispensing mechanism
- Noticed that the motors had metal ends and needed wires soldered to each.
- Tested the motors with a power supply to determine the direction of rotation.
- Used red and black wires, soldering iron, flux, solder, clamp, and wire cutters to solder the wires securely to the motors.
- Ensured the connections were tight to avoid issues.

Entry 3: -----------------------------------------------------------------

Date: February 19th
Start Time: 9:30 AM
Duration: 2 Hours

For this session, I:
Session 4 - Presented progress to the team on all the algorithms.
- Created a GitHub repository to store all the code: SmartCardShuffler Repo
- Spent 20-30 minutes walking Craig through the code I had written as he had to write the final software overview document.
- While pushing the code to GitHub, I lost all the code I had.
- Panicked for a bit, then used tutorials to learn how to recover deleted branches.
- Tutorials Used     • https://www.youtube.com/watch?v=0chZFIZLR_0
    • https://www.youtube.com/watch?v=XX-Kct0PfFc
    • https://www.youtube.com/watch?v=TEbgnl3XXJc&pp=ygUaZ2l0IHJlY292ZXIgZGVsZXRlZCBicmFuY2g%3D
- Commands used to recover files:
   • `git merge recovered-algorithms --allow-unrelated-histories`
   • `git rm`
   • `git merge --abort`
   • `git stash` and `git stash pop`
   • `git branch -r`
- Using the tutorials, I recovered the deleted branch. Then checked out the main branch, resolved the conflicts, and re-merged the deleted branch, popped the unwanted changes, and pushed the new code
- After solving the issue, I spent some time trying to figure out why it happened and how to avoid it:    • Turns out Craig and I were both working on 2 different branches, and both of us tried to merge them, however he did it before me, so by the time I pushed an pulled the changes, the branch I was working on no longer existed
   • Made sure to make multiple backups of code, and set rule to not delete any branches without talking to each other

Entry 2: -----------------------------------------------------------------

Date: February 17th
Start Time: 7:00 PM - 10:00 PM
Duration: 3 Hours

For this session, I:
Showcase of Working Code (Output Generated by code):
Worst Hand Winner:
Common Cards: ['9h', '2h', 'Tc', '2s', 'As']
Player Cards: [['5s', '7s'], ['Qd', '3c'], ['2d', '7h']]
Final Order: {38: '5s', 14: 'Qd', 28: '2d', 2: '7s', 5: '3c', 40: '7h', 4: 'Qc', 48: '9h', 43: '2h', 41: 'Tc', 20: 'Ah', 25: '2s', 18: '9s', 52: 'As', 27: 'Ac', 45: '2c', 29: '4c', 32: '5c', 36: '6c', 44: '7c', 23: '8c', 21: '9c', 3: 'Jc', 26: 'Kc', 42: '3h', 46: '4h', 33: '5h', 9: '6h', 13: '8h', 8: 'Th', 11: 'Jh', 51: 'Qh', 10: 'Kh', 24: '3s', 19: '4s', 35: '6s', 17: '8s', 16: 'Ts', 30: 'Js', 15: 'Qs', 1: 'Ks', 6: 'Ad', 31: '3d', 22: '4d', 47: '5d', 7: '6d', 37: '7d', 49: '8d', 12: '9d', 34: 'Td', 39: 'Jd', 50: 'Kd'}

Poker Game Mode: Specs: total_games = 3
probabilities = [ 0.2, #Player 1 0.05, #Player 2 0.6, #Player 3 0.05, #Player 4 0.1 #Player 5 ]

Designated Winner: 1
Designated Winner: 5
Designated Winner: 3
Common Cards: ['5s', '7h', 'Td', '6d', 'Kd']
Player Cards: [['Qc', 'Qh'], ['Qs', '2h'], ['Tc', '3c'], ['3s', '6h'], ['8s', '2c']]
Order Game #1: {37: 'Qc', 17: 'Qs', 33: 'Tc', 19: '3s', 27: '8s', 2: 'Qh', 48: '2h', 26: '3c', 41: '6h', 40: '2c', 35: '3d', 4: '5s', 11: '7h', 36: 'Td', 25: '4h', 3: '6d', 7: '9d', 30: 'Kd', 12: 'Ac', 28: '4c', 1: '5c', 34: '6c', 38: '7c', 42: '8c', 31: '9c', 21: 'Jc', 45: 'Kc', 15: 'Ah', 52: '3h', 16: '5h', 18: '8h', 46: '9h', 8: 'Th', 39: 'Jh', 20: 'Kh', 22: 'As', 6: '2s', 14: '4s', 51: '6s', 50: '7s', 49: '9s', 13: 'Ts', 10: 'Js', 32: 'Ks', 5: 'Ad', 44: '2d', 43: '4d', 24: '5d', 47: '7d', 9: '8d', 23: 'Jd', 29: 'Qd'}
Common Cards: ['8s', '4d', '7c', 'Kc', '2s']
Player Cards: [['Jc', '9d'], ['Js', '5c'], ['Jd', 'As'], ['Qh', '6c'], ['Qd', '8c']]
Order Game # 2 : {37: 'Qc', 17: 'Qs', 33: 'Tc', 19: '3s', 27: '8s', 2: 'Qh', 48: '2h', 26: '3c', 41: '6h', 40: '2c', 35: '3d', 4: '5s', 11: '7h', 36: 'Td', 25: '4h', 3: '6d', 7: '9d', 30: 'Kd', 12: 'Ac', 28: '4c', 1: '5c', 34: '6c', 38: '7c', 42: '8c', 31: '9c', 21: 'Jc', 45: 'Kc', 15: 'Ah', 52: '3h', 16: '5h', 18: '8h', 46: '9h', 8: 'Th', 39: 'Jh', 20: 'Kh', 22: 'As', 6: '2s', 14: '4s', 51: '6s', 50: '7s', 49: '9s', 13: 'Ts', 10: 'Js', 32: 'Ks', 5: 'Ad', 44: '2d', 43: '4d', 24: '5d', 47: '7d', 9: '8d', 23: 'Jd', 29: 'Qd'}
Common Cards: ['Qs', '6d', '9d', '3c', '7c']
Player Cards: [['3d', '8d'], ['Tc', '4s'], ['9c', '2s'], ['6c', 'Th'], ['Ah', '5s']]
Order Game # 3 : {37: 'Qc', 17: 'Qs', 33: 'Tc', 19: '3s', 27: '8s', 2: 'Qh', 48: '2h', 26: '3c', 41: '6h', 40: '2c', 35: '3d', 4: '5s', 11: '7h', 36: 'Td', 25: '4h', 3: '6d', 7: '9d', 30: 'Kd', 12: 'Ac', 28: '4c', 1: '5c', 34: '6c', 38: '7c', 42: '8c', 31: '9c', 21: 'Jc', 45: 'Kc', 15: 'Ah', 52: '3h', 16: '5h', 18: '8h', 46: '9h', 8: 'Th', 39: 'Jh', 20: 'Kh', 22: 'As', 6: '2s', 14: '4s', 51: '6s', 50: '7s', 49: '9s', 13: 'Ts', 10: 'Js', 32: 'Ks', 5: 'Ad', 44: '2d', 43: '4d', 24: '5d', 47: '7d', 9: '8d', 23: 'Jd', 29: 'Qd'}


- Developed two key poker-related algorithms for the smart card shuffler:
   • Worst Hand Winner Algorithm: Forces a 2-7 offsuit hand to win against other players
   • Probability-Based Game Mode: Controls winning probabilities for different players across multiple games.
-Worst Hand Winner Algorithm (_worst_hand_winner)
   • Purpose: Ensure that the traditionally worst poker starting hand (2-7 offsuit) wins the hand
   • Implementation Details:
     • Generates all possible 2-7 offsuit combinations (12 total variations)
     • Continuously deals random boards and opponent hands until finding scenario where 2-7 wins
     • Uses Treys library's Evaluator for hand strength comparison
     • Once winning combination found, sets up deck ordering to ensure this outcome
     •
   • Pseudocode.
     • while (not found winning combination):
       • Draw 5 community cards for board
       • Deal random hands to other players
       • For each possible 2-7 offsuit combination:
       • Check if cards aren't already used
       • Evaluate hand strength against other players
       • If 2-7 hand wins: stop and break loop
     • Store final card ordering:
       • Player hands first (2 rounds)
       • Burn card (if enabled)
       • Flop (3 cards)
       • Burn card
       • Turn card
       • Burn card
       • River card
     • Remaining cards in random order
- Probability-Based Game Mode
   • Purpose: Control win rates for each player across multiple poker games
   • Key Features:
     • Takes list of winning probabilities for each player
     • Generates multiple game scenarios matching desired probabilities
     • Preserves hand strength authenticity by swapping winning hands
   • Pseudocode:
     • For each game (1 to total_games):
       • Deal board and hands to all players
       • Select winner based on input probabilities
       • Find strongest hand among all players
       • Swap strongest hand to designated winner's position
       • Store card positions and ordering
       • Generate deck order following same pattern as worst hand algorithm
- Technical Implementation Notes
   • Using Treys library for:
     • Card evaluation
     • Deck management
     • Hand strength comparisons
   • Maintaining proper burn card handling throughout dealing process
   • Converting between card representations (integer ↔ string) as needed
   • Managing available cards list to prevent duplicates
   • Preserving original deck ordering through position mapping

Entry 1: -----------------------------------------------------------------

Date: February 17th
Start Time: 2:00 PM - 5:00 PM
Duration: 3 Hours

Showcase of Working Code (Output Generated by code): Poker Random Inform: Common Cards: ['6c', '4s', '6h', '6d', '3s']
Player Cards: [['Kc', '7h'], ['9d', '8h'], ['Qh', '9s']]
Winner is Player: 1
Final Order: {1: 'Kc', 2: '9d', 3: 'Qh', 4: '7h', 5: '8h', 6: '9s', 7: '3d', 8: '6c', 9: '4s', 10: '6h', 11: 'Jd', 12: '6d', 13: 'Td', 14: '3s', 15: '4c', 16: '4h', 17: 'Jh', 18: 'Js', 19: 'Kh', 20: '3c', 21: 'Kd', 22: '2c', 23: 'Qs', 24: '7d', 25: '4d', 26: 'As', 27: 'Ad', 28: '5d', 29: '8d', 30: 'Qd', 31: 'Jc', 32: '6s', 33: 'Qc', 34: '9c', 35: '9h', 36: '2d', 37: 'Tc', 38: '5s', 39: 'Ac', 40: '7c', 41: '2h', 42: '5c', 43: 'Ah', 44: '2s', 45: '3h', 46: 'Ts', 47: '7s', 48: '5h', 49: 'Ks', 50: 'Th', 51: '8s', 52: '8c'}

Showdown Mode:
Common Cards: ['Qc', '3d', 'Tc', '9h', 'Jd']
Player Cards: [['Th', '4d'], ['5h', 'Ks'], ['8h', 'Td']]
Final Order: {4: 'Th', 6: '5h', 46: '8h', 27: '4d', 44: 'Ks', 15: 'Td', 14: 'Ad', 7: 'Qc', 18: '3d', 36: 'Tc', 31: '9d', 34: '9h', 52: '4h', 42: 'Jd', 26: 'Ac', 11: '2c', 39: '3c', 2: '4c', 38: '5c', 21: '6c', 49: '7c', 40: '8c', 51: '9c', 24: 'Jc', 3: 'Kc', 50: 'Ah', 37: '2h', 5: '3h', 10: '6h', 25: '7h', 8: 'Jh', 19: 'Qh', 30: 'Kh', 29: 'As', 33: '2s', 28: '3s', 47: '4s', 9: '5s', 48: '6s', 22: '7s', 13: '8s', 20: '9s', 43: 'Ts', 45: 'Js', 32: 'Qs', 17: '2d', 1: '5d', 16: '6d', 12: '7d', 41: '8d', 35: 'Qd', 23: 'Kd'}

No Pocket Pairs
Common Cards: ['7s', '3s', '4s', 'Jd', 'Qs']
Player Cards: [['Qc', '6s'], ['2s', '5c'], ['4d', '6c'], ['Jh', 'Qd'], ['3c', 'Qh']]
Final Order: {32: 'Qc', 28: '2s', 24: '4d', 35: 'Jh', 49: '3c', 20: '6s', 48: '5c', 34: '6c', 31: 'Qd', 7: 'Qh', 50: '8s', 13: '7s', 17: '3s', 21: '4s', 38: 'Ad', 25: 'Jd', 51: '4h', 41: 'Qs', 4: 'Ac', 39: '2c', 6: '4c', 3: '7c', 12: '8c', 1: '9c', 5: 'Tc', 43: 'Jc', 15: 'Kc', 14: 'Ah', 10: '2h', 44: '3h', 19: '5h', 33: '6h', 37: '7h', 23: '8h', 42: '9h', 30: 'Th', 22: 'Kh', 40: 'As', 16: '5s', 47: '9s', 29: 'Ts', 26: 'Js', 8: 'Ks', 9: '2d', 46: '3d', 11: '5d', 2: '6d', 27: '7d', 45: '8d', 52: '9d', 36: 'Td', 18: 'Kd'}
For this session, I:
- Implemented the poker_random_inform function, which generates a random poker shuffle, simulates the game, evaluates the winner, and returns the results.
- Developed the initial version of the PokerMods class, implementing two poker game modifications:
   1. Showdown Mode: Ensures that at least two players receive a straight or better.
   2. No Pocket Pairs Mode: Guarantees that no player receives a pocket pair.
- Code Explanation in Pseudocode
   • poker_random_inform (PokerShufflerRandomInform Class)
     1. Initialize class variables, including deck order, player count, and whether to burn cards.
     2. Generate a shuffled deck order using RandomShuffler.
     3. Distribute hands:
       • Assign two hole cards to each player.
       • Burn a card if enabled.
       • Deal the flop (three community cards).
       • Burn a card if enabled.
       • Deal the turn (one community card).
       • Burn a card if enabled.
       • Deal the river (one community card).
     4. Evaluate the poker hands using the treys library:
       • Convert card strings to numerical representations.
       • Compute hand rankings.
       • Identify the player with the lowest rank value (best hand).
     5. Return the shuffled order and winning player.
- PokerMods Class (Poker Game Modes)
   1. Showdown Mode
     • Continuously generate random hands and community cards until at least two players have a straight or better.
     • Use treys Evaluator to assess hand strength.
     • Convert the selected board and hands to string format.
     • Store the generated deck order.
   2. No Pocket Pairs Mode
     • Ensure each player receives two hole cards that do not form a pocket pair.
     • Randomly assign community cards.
     • Store the final deck order.

=============== Week 5: =================

Session 5

Entry 4: -----------------------------------------------------------------

Date: Feb 13th
Start Time: 5:30pm
Duration: 1 hour 30 min

For this session, I
First tested the servo implementation that Johnny had printed, by connecting it to power
It worked great, still need to write Arduino code to control it, but working on it right now
I then tried to assemble the SLS printed card dispenser, but the old motors don't fit into it, so could not test it out
I then looked into how we can implement the Raspberry Pi Zero into the PCB
Brendan just wanted simple wires connecting out of it, but I felt like this was not a very professional approach
Came up with two ideas: Solder it in, or have female header pins in exact format to fit the Pi into the PCB
However, as the pins are facing up, it would be facing down towards the PCB, or we could unsolder all the pins of the Pi and resolder them the other way around, to ensure the processor is facing up
Had long discussion with TA and professor, and came to the conclusion to resolder and use header pins.
Firstly should resolder to ensure processor can get enough air, especially as some of our algorithms are computationally heavy
I decided on header pins as this would allow for easy testing, in case there are some problems with PCB, as if we have through holes, those are much harder to rewire
Explained thought process to Brendan and he agreed
Watched these tutorials to understand how to:
https://www.youtube.com/watch?v=CVEsqs1WU0w&pp=ygUXdW5zb2xkZXJpbmcgaGVhZGVyIHBpbnM%3D
https://www.youtube.com/watch?v=CVEsqs1WU0w&pp=ygUXdW5zb2xkZXJpbmcgaGVhZGVyIHBpbnM%3D
https://www.youtube.com/watch?v=9jpotpIO1-U
Found I have good understand of methodology, and plan to resoldering the pins of the Raspberry Pi Zero W next week / week after

Entry 3: -----------------------------------------------------------------

Date: Feb 13th
Start Time: 10:30am
Duration: 3 Hours

Session 4 For this session, I:
Worked on finalizing the poker implementation of this
I first worked on writing the simple implementation of the code, where users as able to choose specific cards
Wrote multiple functions and classes to implement this.
Researched this to completely understand all the rules: https://bicyclecards.com/how-to-play/texas-holdem-poker
Functionality:
User gives user specs:

Session 4 0 represents the common cards. All positions are Any by default, but the user can select which cards to put for who. All this data will be fetched from the phone application
Based on this order, firstly i find a list of all the cards that are not mentioned, so I make sure each card is only used once
I also gave a possible functionality to select "Burn Card". Many people choose to burn cards after each river, however, some don't. So a variable is passed to this class, which will be fetched from user in the phone application (Settings Screen)
Once I have all the cards, I start generating the deck
It loops through each player and places their first card in the order first, then the second
It then based on the burn variable, burns a card
Then puts first 3 rivers
Then burns card (optional)
Then puts the 4th common card
Then burns card (optional)
Then puts the 5th card
All of these go through multiple checks to ensure one card is not repeated. If "Any" is given, a repeated card is seen, then it simply chooses a random card from the available_cards_list, and removes that card from that list
Once the order is decided, it finds the order based on the order of the cards. This works the same way as it does in random shuffle
This eventually leads to this output:
Curr Order: {40: 'SJ', 31: 'HA', 41: 'CK', 49: 'H9', 19: 'S10', 18: 'D5', 36: 'CQ', 14: 'D9', 5: 'CJ', 2: 'D10', 42: 'H7', 25: 'D2', 24: 'SK', 17: 'HK', 20: 'S3', 23: 'D6', 13: 'S9', 16: 'DQ', 28: 'S2', 1: 'DK', 48: 'SQ', 7: 'HQ', 39: 'CA', 47: 'DJ', 35: 'C10', 22: 'D8', 3: 'C7', 26: 'H6', 10: 'S7', 30: 'SA', 37: 'S4', 52: 'S6', 4: 'HJ', 9: 'H2', 11: 'C4', 43: 'C2', 44: 'H8', 6: 'D3', 50: 'C9', 29: 'H4', 12: 'D7', 33: 'H10', 38: 'C6', 32: 'H5', 34: 'D4', 27: 'C5', 15: 'S8', 21: 'C8', 8: 'C3', 51: 'S5', 46: 'DA', 45: 'H3'}
New Order: {38: 'C6', 47: 'DJ', 20: 'S3', 35: 'C10', 1: 'DK', 30: 'SA', 17: 'HK', 39: 'CA', 32: 'H5', 24: 'SK', 31: 'HA', 12: 'D7', 16: 'DQ', 48: 'SQ', 43: 'C2', 8: 'C3', 11: 'C4', 27: 'C5', 3: 'C7', 21: 'C8', 50: 'C9', 5: 'CJ', 36: 'CQ', 41: 'CK', 9: 'H2', 45: 'H3', 29: 'H4', 26: 'H6', 42: 'H7', 44: 'H8', 49: 'H9', 33: 'H10', 4: 'HJ', 7: 'HQ', 28: 'S2', 37: 'S4', 51: 'S5', 52: 'S6', 10: 'S7', 15: 'S8', 13: 'S9', 19: 'S10', 40: 'SJ', 46: 'DA', 25: 'D2', 6: 'D3', 34: 'D4', 18: 'D5', 23: 'D6', 22: 'D8', 14: 'D9', 2: 'D10'}
If you see the new order perfectly matches how cards should be dispensed based on user specs
I then researched different methods on how I can implement the stretch PSDRS
I first wanted to come up with a list of functionality for it.
I settled on the following:
"Random Shuffle" - This mode would generate a randomly shuffled deck, but it would calculate who would win the game, and tell it back to the user, so they can choose to play
Very computationally difficult
Need to send data back to app, adds extra complexity
"Set of Games" - Allows user to select players, and how many rounds they want to play. They can assign luck probabilities to each player
Very computationally difficult
Need to create a whole new UI to go to next round
"Poker Mods": Allows user to add specific modifications to the game. This would include make the game high stakes (ensure aces are near the top), show down mode (ensure 2 very strong hands given to users, makes it very interesting), No Pocket Pairs mode (ensure no one gets pairs from the start), etc.
Extremely computationally difficult, as need to calculate all of these on the Pi
Still yet to start implementing these, however, looked through reference Poker libraries for potential use cases, as writing code to compare hands will be extremely difficult
https://medium.com/@mfonism/poker-hand-comparison-964fd2644ccc
https://github.com/ihendley/treys/tree/master
https://github.com/ihendley/treys
https://pypi.org/project/poker/
https://github.com/tylerjustinfisher/poker-hand-comparator
Tentatively finalized using treys functions, as they appear to be the fastest, and don't have functions I don't need, that some of the other libraries do.

Entry 2: -----------------------------------------------------------------

Date: Feb 12th
Start Time: 10:30 am
Duration: 2 hours 30 min

Session 4 Session 4 For this session, I:
Met with my team in Man Lab
Spent approx 20 minutes discussing what progress each of us had made over the weekend
I presented the code I had written
Team really liked it, and thought that this implementation made a lot of sense
We then discussed on how I should go about implementing the poker algorithm for our project
Craig really wanted to have a simple select for all cards
While this was much easier for me to do, I felt that this implementation is not really a good interface as it would take a lot of time to use
I wanted a more modular approach, which would allow the user to select probabilities and or specific hands they should get. Ie. a suited straight. Realistically I felt that not many users would care about having a 4567 versus a 7689.
We came to the conclusion, to ensure we are able to implement, lets set the basic methodology as our requirement, and the remaining as stretch PSDRs
I decided to leave the rest of the decisions on how to implement the stretch for later in the week
I then worked with Johnny to come up with the trap door mechanism to allow cards to exit.
Johnny wanted a simple trap door that would open in a circular way, however, I wanted a linear motion that would open and shut.
The reason I was against the circular motion was that even though it is easier to implement, it will likely take a relatively longer amount of time to open
This is because the linear door only has to open a couple of millimeters to allow the card to slide out, where as the circular motion needs to allow for the entire mechanism to get out the way
We finally decided on the linear trap door
I researched some mechanism and found these resources:
https://www.youtube.com/watch?v=2vAoOYF3m8U
https://www.youtube.com/watch?v=Fde2lwK3yqU
https://www.youtube.com/watch?v=pClmobqMa-A
Finalized: https://www.thingiverse.com/thing:3170748
With these CAD models, it makes Johnny's life a lot easier as he only needs to edit the files, rather than making them from scratch
I also looked into a linear actuator (3rd video). While this would make it faster, Johnny I felt that this would really not have that much actual time difference, and would only be relatively faster. We decided to go with the simpler servo implementation
I then went to the ME Shop to fetch a servo motor. In the shop, we found a couple of different ones, including 9gram, model 30003, 35kg servo motor.
After doing some quick research their, I decided Model 30003 would be the best. This is because the 9 gram is too weak and hence will take a lot of time, where as the 35kg servo requires too much power, and hence will overly complicate without adding much value

Entry 1: -----------------------------------------------------------------

Date: Feb 10th
Start Time: 6pm
Duration: 2 hours

For this session, I
Made the decision to minimize for time in App
Came up with implementation for Random Shuffle
How it works:
Takes current order as input, this is why a post sort is much better than pre sort as it allows for optimizations after filling the deck
Generates random shuffle based on Fisher Yates algorithm
Used this as reference: https://www.geeksforgeeks.org/shuffle-a-given-array-using-fisher-yates-shuffle-algorithm/
It loops through the entire new generated order, and calculates the difference from where it starts to where it needs to go. Ie. (dispense card 5 of hearts at slot 23, when originally at slot 11, hence will travel 12 positions)
Once it has gone through the loop, it sums the total distances to find the total distance
Also accounts for that it can go in either direction, so it calculates the absolute value, hence can find that slot 2 does not need to travel left 51 positions, and can just travel right 1 position to slot one
Example of implementation:
Original Order: {31: 'H10', 46: 'D5', 32: 'H7', 1: 'C9', 45: 'S5', 47: 'CK', 43: 'C6', 26: 'H6', 36: 'H8', 11: 'C10', 30: 'C2', 24: 'S2', 6: 'S10', 52: 'D7', 35: 'S7', 19: 'DJ', 50: 'HK', 34: 'SJ', 40: 'H2', 37: 'D3', 28: 'DA', 21: 'S6', 49: 'H3', 2: 'S3', 27: 'C4', 13: 'C3', 33: 'D9', 15: 'HA', 22: 'SA', 18: 'C8', 51: 'H4', 17: 'D6', 14: 'S8', 9: 'CJ', 3: 'D10', 41: 'C7', 7: 'DK', 20: 'CA', 16: 'D8', 25: 'DQ', 10: 'D2', 4: 'SQ', 12: 'D4', 23: 'HJ', 29: 'S9', 5: 'C5', 48: 'CQ', 44

=============== Week 4: =================

Entry 6: -----------------------------------------------------------------

Date: February 7th
Start Time: 4:30 PM
Duration: 3 Hours

Session 4 Session 4 Session 4 Session 4 For this session, I:
- Wrote all the code to generate the new order for the cards, except for Poker. Still need to research that more.
- Created these files:
   • main.py: Calls functions.
   • Curr_order.py: Fetches current order from Flutter App.
   • Random_shuffle.py: Creates a random shuffle order.
   • Custom_shuffle.py: Handles all the custom requirements for the custom page in the Flutter App.
     - Unopened_pack: Sorts cards A-K in the format of Clubs, Hearts, Spades, Diamonds.
     - Both_colors_separated: Dispenses all red cards first, then all black cards.
     - Card_on_top: Brings a specified card to the top; the rest are dispensed in the original order.
     - Palindrome: Dispenses cards in a palindrome (A-K, K-A), first red, then black.
     - Insert_num_start: Allows a specific number to be put on top, ensuring no number repeats more than 4 times. The rest of the cards are dispensed in order.

Entry 5: -----------------------------------------------------------------

Date: February 6th
Start Time: 5:30 PM
Duration: 1 Hour 30 Minutes

Session 4 Session 4 For this session, I:
- Assembled the new design.
- Ensured the motors had a strong connection.
- Spent 30 minutes trying to control motors with Arduino but found no success.
- Spent 10 minutes controlling motors using power cables but realized it wasn’t working.
- Consulted the Lab TA for 15 minutes but couldn’t find motor datasheets.
- Lab TA recommended avoiding these motors due to lack of documentation.
- Tried using a drone motor but found its RPM was too high for our needs.
- Determined we needed approximately 120 RPM, while the drone motor exceeded 1000 RPM.

Entry 4: -----------------------------------------------------------------

Date: February 6th
Start Time: 12:00 PM
Duration: 20 Minutes

For this session, I:
- Went to Bechtel to pick up the new design Johnny had printed.

Entry 3: -----------------------------------------------------------------

Date: February 5th
Start Time: 10:30 AM
Duration: 2 Hours

Session 4 Session 4 Session 4 For this session, I:
- Helped Johnny assemble all motors and parts.
- Connected motors to Arduino and ensured a tight fit.
- Added electrical tape to rollers to increase friction.
- Wrote Arduino code to control motors for card dispensing:
   • Back motor runs → Wait → Forward motor runs → Stop back motor → Wait → Stop forward motor → Repeat.
- Faced issues with the code and directly tested motors by connecting them.
- Went to ME Shop for 12V motors and drivers.
- Realized 5V motors were too weak for fast card dispensing.
- Acquired two 12V motors with built-in encoders.

Entry 2: -----------------------------------------------------------------

Date: February 4th
Start Time: 6:00 PM
Duration: 20 Minutes

Session 4 For this session, I:
- Went to Bechtel to pick up parts Johnny had printed.

Entry 1: -----------------------------------------------------------------

Date: February 1st
Start Time: 4:00 PM
Duration: 3 Hours

Session 4 Session 4 Session 4 For this session, I:
- Wrote down and researched all requirements for A3 Software Overview.
- Created a state machine diagram for documentation.
- Researched the following software components:
   • Bluetooth Protocols: Finalized BLE.
   • Pi BLE Stacks: Finalized BlueZ Stack.
   • BLE-Compatible Profiles: Finalized GATT.
   • Cameras compatible with Pi: Finalized Raspberry Pi AI Camera.
   • OpenCV Functions: Finalized those listed in documents.
   • Camera Recognition Models: Finalized YOLO V8.
- Finalized the Fisher-Yates Random Shuffle Algorithm.
- Found the Hungarian Algorithm for Poker; more research needed.
- Created an error-handling protocol.
- Defined data storage structures and how they move between devices (listed in A3).

=============== Week 3: =================

Entry 6: -----------------------------------------------------------------

Date: January 31st
Start Time: 8:00 PM
Duration: 1.5 Hours

For this session, I:
- Worked on A3 Software Overview.
- See BrightSpace and Group Website for completed work.

- Created below flowcharts

Session 5 Session 5 Session 5 Session 5

Entry 5: -----------------------------------------------------------------

Date: January 30th
Start Time: 8:00 PM
Duration: 2.5 Hours

For this session, I:
- Watched this tutorial: Figma App Design Tutorial
- Learned skills on using UI, importing elements from existing packages, designing, grouping components, linking pages, making footers, and adding important images.
- Came up with the entire design functionality and flow.
- Found some “fun” uses under the custom tab.
- Got feedback from the team on improvements.
- Added functionality in the Poker page to select specific cards.

- Session 4 Session 4

Entry 4: -----------------------------------------------------------------

Date: January 30th
Start Time: 5:30 PM
Duration: 1 Hour

For this session, I:
- Resoldered some wires as they broke.
- Acquired all wires in the lab to test motors on Arduino.
- Connected and wired up the circuit to Arduino.
- Installed Arduino IDE and wrote some basic testing code with Johnny.
- Verified all parts are working.
- Discussed current progress with the team and set goals for next week:
    Krish: Create Figma profiles. Test the design once Johnny finishes printing.

- Session 3 - Session 3

Entry 3: -----------------------------------------------------------------

Date: January 30th
Start Time: 10:30 AM
Duration: 20 Minutes

For this session, Johnny and I:
- Met to review the design he had created.
- Discussed the need for a 2-roller design at the exit, which he had missed.
- Helped him double-check all measurements.

-

Entry 2: -----------------------------------------------------------------

Date: January 29th
Start Time: 8:00 PM
Duration: 1 Hour 30 Minutes

For this session, I:
- Learned Fusion 360 as Johnny, the lead CAD designer, prefers it.
- Watched the following tutorials:
    Fusion 360 Tutorial 1
    Fusion 360 Tutorial 2
    Fusion 360 Tutorial 3
    Fusion 360 Tutorial 4
- Learned skills including sketching, extruding, revolving, lofting, managing planes, drawing in sketches, and UI usage.
- Made a basic design to test these skills.

- Session 2

Entry 1: -----------------------------------------------------------------

Date: January 29th
Start Time: 9:30 AM
Duration: 2 Hours 30 Minutes

For this session, I:
- Proposed splitting into smaller teams to focus on individual components:
    Card dispenser, wheel, STM32 setup, dropping mechanism, etc.
- Finalized teams:
    Johnny and I will focus on the card dispenser, Craig and Brendan on STM32 setup.
- Researched card dispenser designs:
    Design 1
    Design 2
    Design 3
    Design 4
    Design 5
- Summarized research into two possible designs:
    1. Wheel on top.
        Pros: Easy, simple design; no weight needed on top; fewer stuck cards.
        Cons: Inconsistent card location; harder speed control.
    2. Two-roller design at the bottom.
        Pros: Easier speed control; consistent dispensing location.
        Cons: Requires 2 motors; more CAD and testing time.
- Finalized the two-roller design after discussion.
- Created design requirements:
    Use 2 gear motors, a precise slot for cards, and ensure 52 cards dispense in under 30 seconds.
- Helped Johnny start the CAD model and reviewed measurements.
- Acquired 2 gear 5V motors from the ME shop and soldered wires and capacitors in the MAN lab.

- Session 1

=============== Week 2: =================

Entry 5: -----------------------------------------------------------------

Date: January 24th
Start Time: 1:30pm
Duration: 1 Hour

For this session, we:
- Met with ECE Shop Machinist Chuck
- Presented both ideas
- Took initial Meaurements:
- Card width approx 0.3mm
- Learned the need to use AutoCAD to work with ECE Shop tools
- Got understanding of available tools at ECE Shop
- Chuck said wheel design is likely to create less bottleneck - Finalized wheel Design
- Learned need to use imperial units for machines in ECE Shop

Session 5
Developed some basic designs for Wheel
- Created pro con list for whether to Presort (Put cards in order they should be dispensed) or Postsort (put all 52 cards in subsequent trays and move wheel each time to dispense correct position)
- Decided Post Sort will never be slower; Need to test time to dispense card after large wheel rotation to ensure that does not change decision.

Entry 4: -----------------------------------------------------------------

Date: January 23rd
Start Time: 5:30pm
Duration: 2 Hours

For this session, we:
- Set tasks for functional report
- Set time to meet Machinist at: 1:30pm
- Decided to set roles for Project (Tentative):
- Set roles to ensure to make expectations; planning; ensure everyone is working on what they want
- Made sure to mention all should try and work in each part a bit for understand and learning purposes
Session 4

Entry 3: -----------------------------------------------------------------

Date: January 22nd
Start Time: 9:30am
Duration: 2 Hours

For this session, we:
- Drew both ideas on whiteboard
- Came up with Pro / Con List
- Discussed which idea we each preferred and for what reason
- Presented both ideas to Prof Walter and TAs, mentioned both are feasible but mechanically heavy; Prof Walter mentioned he preferred wheel design
- Set next goal to meet with machinist; as was not available at that time
- Acquired components: Raspberry Pi 4, STM 32 F7 Dev Board, Camera
- Set basic requirements for Motors: Stepper, high torque
- Conclusion: Decide design based on which has less chance of having a strong mechanical bottleneck; Next step consult ECE Shop Machinist Chuck for advice

Session 3 2 Ideas:
- Wheel: 52 individual slots; Card Tray to put one card in each slot. Motorized trap door at bottom to re put the cards in correct order
- Tray Design: Have 8-13 trays where cards will be placed one by one (Tray / Card Tray moves up / down). Stack cards based on desired order; Restack cards by collecting from tray

Entry 2: -----------------------------------------------------------------

Date: January 21st
Start Time: 5:30pm
Duration: 0.25 Hours

For this session, we:
- Met to Set Goals for the Week
- Research Components
- Finalize which design to choose
- Functional Report
- Website

Entry 1: -----------------------------------------------------------------

Date: January 20th
Start Time: 1:00pm
Duration: 1 Hour

For this session, we:
- Johnny and I researched similar projects
- Found: https://www.youtube.com/watch?v=eMTXyl7tPEk
- Found: https://www.youtube.com/watch?v=EKzgN_-8iP4
- Watched videos in detail understood limitations / expectations
- Developed 2 ideas based on these videos in our head

=============== Week 1: =================

Entry 4: -----------------------------------------------------------------

Date: January 16th
Start Time: 8:00pm
Duration: 1 Hour

For this session, we:
- Reviewed our final proposal
- Met on Discord
- Set PSDRs and brief functionality

Entry 3: -----------------------------------------------------------------

Date: January 16th
Start Time: 5:30pm
Duration: 0.5 Hours

For this session, we:
- Discussed idea with Prof Walter
- Understood that project had previously been attempted, but team were unsuccessful
- Acknowledged it is a mechanically heavy project
- Assigned roles for final proposal

Entry 2: -----------------------------------------------------------------

Date: January 15th
Start Time: 9:30am (Man Lab)
Duration: 2 Hours

For this session, we:
- Presented ideas to TAs
- Got tour of lab and equipment
- Understood checkout process
- We each presented our ideas, Craig’s smart card shuffler was picked, as we all were very intrigued and excited about it
- Came up with basic functionality: Real Random Shuffle, Organize deck in any order, Change odds of winning in Poker

Entry 1: -----------------------------------------------------------------

Date: January 14th
Start Time: 5:30pm
Duration: 0.5 Hours

For this session, we:
- Discussed our plan
- Johnny and I mentioned we aren’t interested in guitar amplifier just because it is not very exciting and is not unique
- Craig and Brendan agreed
- We suggested braille display idea, but Craig and Brendan weren’t as interested due to its applications being very specific
- Decided to brainstorm, mentioned to take the night to come up with ideas so we don’t rush