Project

# Title Team Members TA Documents Sponsor
78 Wearable Basketball Jumpshot Mechanics Analyzer
Aiden Zack
Arjun Vyas
Tanmay Nair
Mingrui Liu proposal1.pdf
Tanmay Nair (netid: tanmayn2 )
Arjun Vyas (netid: avyas9)
Aiden Zack (netid: aidenrz2)

Problem: A basketball jumpshot involves a chain of body mechanics that requires coordination from your feet to your wrist to achieve a simple goal that is much more complicated than what the average person sees: Making the ball go in the hoop. So many players across the world have exhibited different mechanics in their jumpshot, so when they reach out to coaching for help, they tend to hear subjective advice that is often inconsistent, difficult to put into numbers, and, more importantly, harder to fit into the player’s perspective. Existing resolutions utilize shot trajectory and do not tap into the biomechanics that reside in the shooter. In essence, this leads to players lacking reliable, repeatable data to identify points of improvement in their mechanics, address consistency issues, and record progress.

Solution: This project will implement a system dedicated to quantifying a user’s basketball jumpshot by analyzing the consistency and timing of the “kinetic chain”. It starts with node sensors that will be worn on the user's shooting wrist and the knee of the user’s shooting side. These sensors will hold an IMU, microcontroller, and wireless (or wired, tbd) communication. The knee sensor will focus on lower-body motion and take measures related to shot success, such as the timing of the jump and how much the knee flexes to determine the dip. The wrist sensor will look at the upper-body mechanics that finish out the shot, like the angular velocity and release timing of the wrist, along with how high it sits for the follow-through. These 2 data nodes will be synchronized in our system, extracted for timing measures like jump-to-release, and then processed for evaluation and feedback. This will focus on the repeatability and timing of the user’s body mechanics, providing user-oriented assistance that adjusts as the user progresses.

Solution Components: PCB, Li-Po Battery Pack, USB-C Charging Port, SPI/I2C Communication Bus, IMU Sensors (3-axis accelerometer + 3-axis gyroscope), FPGA*, PCB Chest Harness.

*FPGA may not be needed if we decide to use specific types of IMU sensors with FSYNC/SYNC capability to trigger sampling on the same external edge.

Subsystem 1: IMU Sensor on the Knee
This IMU sensor will be worn on the user’s shooting leg, right above the knee, along the side of the femur. The important metrics to grab from here will be the displacement and angular rotation with respect to the zero-calibration (standing straight up). This IMU will be synchronized with the other IMU sensor on the wrist, being sampled under a SPI/I2C communication bus that will carry data from the sensors to the PCB, which will then be processed and sent to the FPGA via USB/UART.

Subsystem 2: IMU Sensor on the Wrist

This IMU sensor will be positioned on the back of the user's thumb to accurately record the motion of the wrist. The key metrics we are looking for are angular velocity, physical displacement, and the timing between each of the 3 phases between the movements. The angular velocity can be determined by seeing the physical start and end positions of the wrist motion during phase 3 of the shot, divided by the elapsed time. The 3 phases of the shot are
Raising the ball (Shoulder Movement)
Pushing the ball forward (Chest Movement + Elbow Extension)
Releasing the ball (Wrist Movement)

Subsystem 3: PCB

The PCB is the centerpiece of all external component communications. The 2 IMU sensors will communicate with the MCU on the PCB via I2C/SPI. The MCU will then send the data to the computer over USB/UART. The data will be interpreted in Python using closed-loop feedback communications with the user.

Criterion For Success:
Wrist and knee IMU sensors accurately record motion data
Communication buses accurately read the data off the IMU sensors with low latency and send it to the MCU on the PCB
The MCU can communicate with the computer via USB/UART
We can see the telemetry data, observe significant changes (edge detection/triggers) in behavior via measurements, and quantify these changes in order to provide feedback to the user based on their input.

Antweight Battlebot Project

Jeevan Navudu, Keegan Teal, Avik Vaish

Antweight Battlebot Project

Featured Project

# Antweight Battlebot

Team Members:

- Keegan Teal (kteal2)

- Avik Vaish (avikv2)

- Jeevan Navudu (jnavudu2)

# Problem

In order to compete in Professor Gruev’s robot competition, there are many constraints that need to be met, including:

- Maximum weight (2lbs)

- Allowed materials (3D-printed thermoplastics)

- Locomotion system and fighting tool

- Wireless control via Bluetooth or Wifi

The main goal of this competition is to design a Battlebot that is capable of disrupting the functionality of the other Battlebots with our fighting tool while maintaining our own functionality.

# Solution

For the project, we plan to build a battlebot with a custom electronic speed controller (ESC) that can independently control three brushless motors: two for the drive system, and one for the fighting tool. This ESC will be controlled by an STM32 microcontroller, to which we will add a Bluetooth module to connect to it and specify how much power we want to send to each motor. To communicate with our robot, we will use a laptop that can connect to Bluetooth.

# Solution Components

## Vehicle Controller

The main subsystem of the robot will be a combined vehicle control board and ESC. This subsystem will contain an STM32 Microcontroller that will serve as the brain for the whole robot. With this MCU, we’ll be able to flash our whole software package that will be able to control the speed and direction of the robot, the robot’s weapon, and the Bluetooth communication.

## Power Module

This subsystem includes the battery, the voltage regulators/converters needed to power the electronics, and the necessary battery monitoring circuitry. Specifically, for the battery, we will use a 14.8V 4S2P LiPo pack to power all the components. There will also be a voltage short detection circuit for the battery that will shut down the robot in case of a short to ensure safe practices. This subsystem also contains a 5V linear regulator and 3.3V linear regulator to power the low voltage electronics.

## Drivetrain/Powertrain

This subsystem includes the motors and H-bridges needed to control both the wheels and weapon of the robot. The H-bridges will be made with regular N-MOSs that will be controlled by a PWM signal sent from the STM32 MCU. This H-bridge setup will be able to control the voltage and polarity sent to the motors, which will be able to control the speed of the wheels or weapon. This subsystem will also include the mechanical wheels of the robot and actual hardware of the weapon, which will be a spinning object. Since all the wheels and the weapon have the same mechanical motion, they can all use the same hardware and software electronically, with minor adjustments in motor selection and the actual mechanical hardware/peripheral.

## Bluetooth Module

One big requirement for this project is the ability for the robot to be controlled wirelessly via laptop. The STM32 MCU has bluetooth capabilities, and with additional peripheral hardware, the robot will be able to communicate over bluetooth with a laptop. The goal for the laptop is to be able to control the speed, direction, and weapon of the robot wirelessly and also have a display for live telemetry.

## Mechanical Design

The last part of our project would be the mechanical design of the robot chassis and weapon. For the chassis and weapon material, we decided to go with PLA+ as it offers a blend of being strong and robust but not being too brittle. The drive system will be a 2-wheeled tank style drive with one motor controlling each side of the robot. For the weapon, we are looking to utilize a fully 3D-printed drum that will have a 100% infill to maximize the rotational inertia which can lead to bigger impacts.

## Criterion for Success

We would consider our project a success if we are able to communicate with the robot from our computer as in sending throttle and steering commands to the robot, if those commands are then processed on the robots microprocessors and the motors are sent the according power needed to move and behave in the way that we want during a match.

## Alternatives

The most commonly used electronics in current antweight battlebots consist mostly of RC drone parts. We plan to create a very similar ESC to those on the market but it will have an integrated Bluetooth wireless capability as well as telemetry monitoring. We also want to focus on minimizing packaging size to lower weight and increase flexibility as much as possible.

Project Videos