Project

# Title Team Members TA Documents Sponsor
85 Poker Buddy: Chipless Poker Companion
Austin Abraham
Lorenzo Dumitrescu
Vishal Ramvelu
Eric Tang design_document1.pdf
final_paper1.pdf
photo1.png
presentation1.pptx
proposal1.pdf
video
# Poker Buddy: Chipless Poker Companion

# Team Members:
- Austin Abraham (austina5)
- Lorenzo Dumitrescu (ldumit4)
- Vishal Ramvelu (ramvelu2)

# Problem
Traditional poker games rely heavily on physical chips for betting, which can be cumbersome, error-prone, and prone to mismanagement or theft. Managing chip counts, handling physical money, and tracking bet amounts often slow down the game and can lead to disputes among players. In addition, determining whose turn it is during fast-paced games can be confusing and cause a lot of frustration between players. With the growing demand for digital integration in gaming, there is an opportunity to streamline the poker experience by eliminating physical chips and automating bet tracking and game flow. This is different from online poker because we want to maintain the in person experience of playing against your friends face to face, but without the inefficiencies of standard chips and markers that represent blinds.

# Solution
We propose a modular device that removes the need for physical chips while enhancing the poker-playing experience. Each player will use a dedicated device that features LED displays to show both their current balance and the money in the pot, along with a built-in turn indicator light that activates when it is their turn. We will use a force sensitive touch sensor to interpret different gestures—one tap for fold, two taps for check, and a long hold for call—eliminating the need for manual chip handling to signal actions. Additionally, five colored buttons correspond to different chip denominations for quick and easy betting. While we could use some type of sensor for these buttons, we want to maintain the tactile feel and choose to use buttons for our design. These devices will wirelessly connect to a centralized mobile/web application that manages buy-ins, tracks all player balances, and synchronizes game status in real time, ensuring an efficient and error-free gaming experience. Although these devices will not track cards, they must handle the real-time logic of betting, maintaining balances, and managing turn order without relying on a computer.
The game logic is distributed and managed by the PCBs in each Poker Buddy. This means that each Poker Buddy keeps track of:
- Whose turn it is to bet (reflected by the turn signal LED).
- The current bet amounts and how they contribute to the pot(reflected by LCD display).
- The players’ individual balances(reflected by another LCD display).
- The outcome of each hand (i.e., when a player wins, the entire pot is automatically credited to their balance).
These devices communicate wirelessly with each other and can optionally sync with a centralized mobile application for overall game monitoring and account management by the host of the game (this will just be used for buying in chips and determining payouts at the end). The system is designed to be portable and is powered by disposable batteries, ensuring flexibility and ease-of-use in various settings.

# Solution Components

## Sensor Subsystem
The Sensor Subsystem captures all user inputs without the need for physical chips:
- Force Sensitive Touch Sensor: An FSR (Force Sensitive Resistor) module will detect user gestures and differentiate between a single tap (fold), double tap (check), and long press (call) based on the force and duration of touch.
- Button Array: A set of 5 tactile push buttons, each in a distinct color, will represent specific chip denominations for placing bets.
## Microcontroller and Processing Subsystem
This subsystem processes inputs, drives outputs, and manages wireless communication:
- ESP32-WROOM-32 Module: Serving as the core microcontroller, the ESP32 provides built-in WiFi/BLE connectivity for real-time data exchange with the mobile/web application as well as handling the logic for the game.
- LED Displays: Two displays (7-segment LED displays such as the LTL-307EE) will show the player's balance and the current pot amount.
- Turn Indicator LED: A dedicated LED will signal when it is the player's turn, ensuring immediate visual recognition.
- Voltage Regulator: A voltage regulator such as the LM2596 DC-DC Buck Converter will ensure a stable power supply to the ESP32 and peripheral components.
- Power Supply – Disposable Batteries: The device is designed for portability and can be powered by disposable batteries (AA battery packs) or via a direct power connection.

## User Subsystem
The User Subsystem integrates physical device interaction with a digital game management system:
- Physical Interface: The combination of the LED displays, turn indicator, force sensitive touch sensor, and colored buttons creates an intuitive interface that replaces traditional chip handling.
- Mobile/Web Application: A dedicated application will allow users to buy in, view real-time balances, monitor the pot, and receive instant updates on game status, seamlessly synchronizing data across all devices.
- Secure Communication: Robust wireless protocols will ensure that all transactions and game data are transmitted securely and accurately between the Poker Buddy devices and the central application.

# Criterion For Success
- Real-Time Status Updates: The system must update player balances, pot amounts, and turn indicators on the app within five seconds in at least 90% of cases.
- Accurate Gesture Recognition: The force sensitive touch sensor should reliably distinguish between a single tap (fold), double tap (check), and long press (call) with a false detection rate below 2%.
- Reliable Wireless Communication: The ESP32 module must maintain stable and consistent connectivity with the mobile/web application, achieving at least a 90% connection success rate during active gameplay.
- User-Friendly Interface: The physical device should offer clear visual feedback through its LED displays and turn indicator, ensuring that users can operate it intuitively without the need for physical chips.
- Game is Mathematically Correct: Since poker involves complex betting logic, the system must correctly update sums, properly rotate blinds around the table, and accurately calculate winnings. The distributed game logic must ensure that all arithmetic and game state transitions are mathematically correct and robust against errors.

Decentralized Systems for Ground & Arial Vehicles (DSGAV)

Mingda Ma, Alvin Sun, Jialiang Zhang

Featured Project

# Team Members

* Yixiao Sun (yixiaos3)

* Mingda Ma (mingdam2)

* Jialiang Zhang (jz23)

# Problem Statement

Autonomous delivery over drone networks has become one of the new trends which can save a tremendous amount of labor. However, it is very difficult to scale things up due to the inefficiency of multi-rotors collaboration especially when they are carrying payload. In order to actually have it deployed in big cities, we could take advantage of the large ground vehicle network which already exists with rideshare companies like Uber and Lyft. The roof of an automobile has plenty of spaces to hold regular size packages with magnets, and the drone network can then optimize for flight time and efficiency while factoring in ground vehicle plans. While dramatically increasing delivery coverage and efficiency, such strategy raises a challenging problem of drone docking onto moving ground vehicles.

# Solution

We aim at tackling a particular component of this project given the scope and time limitation. We will implement a decentralized multi-agent control system that involves synchronizing a ground vehicle and a drone when in close proximity. Assumptions such as knowledge of vehicle states will be made, as this project is aiming towards a proof of concepts of a core challenge to this project. However, as we progress, we aim at lifting as many of those assumptions as possible. The infrastructure of the lab, drone and ground vehicle will be provided by our kind sponsor Professor Naira Hovakimyan. When the drone approaches the target and starts to have visuals on the ground vehicle, it will automatically send a docking request through an RF module. The RF receiver on the vehicle will then automatically turn on its assistant devices such as specific LED light patterns which aids motion synchronization between ground and areo vehicles. The ground vehicle will also periodically send out locally planned paths to the drone for it to predict the ground vehicle’s trajectory a couple of seconds into the future. This prediction can help the drone to stay within close proximity to the ground vehicle by optimizing with a reference trajectory.

### The hardware components include:

Provided by Research Platforms

* A drone

* A ground vehicle

* A camera

Developed by our team

* An LED based docking indicator

* RF communication modules (xbee)

* Onboard compute and communication microprocessor (STM32F4)

* Standalone power source for RF module and processor

# Required Circuit Design

We will integrate the power source, RF communication module and the LED tracking assistant together with our microcontroller within our PCB. The circuit will also automatically trigger the tracking assistant to facilitate its further operations. This special circuit is designed particularly to demonstrate the ability for the drone to precisely track and dock onto the ground vehicle.

# Criterion for Success -- Stages

1. When the ground vehicle is moving slowly in a straight line, the drone can autonomously take off from an arbitrary location and end up following it within close proximity.

2. Drones remains in close proximity when the ground vehicle is slowly turning (or navigating arbitrarily in slow speed)

3. Drone can dock autonomously onto the ground vehicle that is moving slowly in straight line

4. Drone can dock autonomously onto the ground vehicle that is slowly turning

5. Increase the speed of the ground vehicle and successfully perform tracking and / or docking

6. Drone can pick up packages while flying synchronously to the ground vehicle

We consider project completion on stage 3. The stages after that are considered advanced features depending on actual progress.

Project Videos