Project

# Title Team Members TA Documents Sponsor
10 3D Printed Antweight Battlebot
Brian Pau
Don Lazatin
Shashank Sangireddy
Jason Jung design_document1.pdf
final_paper1.pdf
grading_sheet1.pdf
proposal1.pdf
video
# Antweight Battlebot Competition Request for Approval

Team Members:
- Don Lazatin (dlazat2)
- Shashank Sangireddy (ssangi2)
- Brian Pau (bnpau2)

# Problem


For our project, we plan on competing in Professor Gruev’s Antweight Battlebot Competition. In order to do so, our Battlebot must adhere to several limitations and requirements. The requirements are listed below

- Battlebot must be less than 2lbs
- Battlebot must be constructed using 3D printed materials
- Battlebot must have a PCB controlled via PC through Bluetooth or Wifi
- Battlebot must have an attached fighting tool that will be activated by the motors
- Battlebot must have a way of easy manual shutdown and automatic shutdown
- Battlebot must adhere to in-competition rules

Our overall goal for this project is to design, build and program a Battlebot object that is capable of disabling competing Battlebot objects with our fighting tool.


# Solution

We plan to build a battlebot with a destabilizing wedge as our fighting tool. We’ve decided to 3D print various parts of the battlebot’s body, such as the chassis and wheels. We will incorporate at least two different kinds of thermoplastic, PLA+ and PETG, according to their relative strengths.
We’ve decided to go with a ESP32-S3-WROOM-1 for our microcontroller, which is responsible for controlling the connected motors. We chose this microcontroller for its superior flash memory space and built-in antenna for Bluetooth communication. In the event that a Bluetooth based protocol is not viable for our design, this microcontroller will allow us to pivot over to a WiFi based protocol.
There will be at least 3 separate motors in use: one motor may be a brushless motor used for activating the fighting tool, and the other two may be DC-powered micromotors that will be used to activate the battlebot’s wheels for mobility. This set of wheels will be driven by H bridge, implemented using N-channel MOSFETs, which would enable precise control of forward-backward movement.
The battlebot will be powered using a rechargeable 9V battery, with current-restricting circuit components such as step-down circuitry or chips incorporated to protect the rest of the circuit from excess voltage.


# Solution Components

## Subsystem: Chassis

The chassis of a battlebot should be thought of as the body and structural base for a competing battlebot. Our chassis will be 3D-printed out of PLA+ filament to ensure a strong armor and follow the weighting guideline for the competition. The chassis will house and protect the main circuit, motors, weaponry, and power source for our device.

Our chassis will have a symmetrically horizontal structure so that if our battlebot is flipped over in competition, it will still have the same operational effectiveness as it would on its original side. We plan on constructing a square-like bodily structure so that there would be no weak side of the chassis for other bots to target. We plan on covering all the electronic components within the body to ensure safety and protection for the internal core of the battlebot.

## Subsystem: Drive System

For our battlebot’s drive system, we plan on producing a 2-wheel drive mechanism with the front of the chassis (weapon) dragging across the floor on top of powerless mini wheels. For the tire treads, we plan on looking into rubber-like materials in order for our battlebot’s movement to be controllable and smooth during operations.

For our battlebot’s drive motor, we plan on using a type of DC-powered micro motor. We are choosing to propose this motor as it would be ideal for a battlebot competition environment. With these types of motors, they significantly reduce the motor’s rotational speed and significantly increase the torque. This is ideal because we are not in need of much speed in a competition arena. Rather, the increase in power output would be more beneficial.

## Subsystem: Weapon System

The fighting tool will be a wedge, designed to lift the opposing battlebot with the intent to destabilize, disorient, and ultimately flip the opponent over. It will be located in front of the battlebot, and will consist of at least 30% of the battlebot’s weight. This amount of mass, combined with motor activation for high amounts of power should result in an effective destabilizing fighting tool, fit to render the opposing battlebot unable to function.
The wedge “weapon” will also be fitted with small, free-moving rubber wheels on its outer surface. The purpose of these wheels is to guide the opposing battlebot’s chassis along the surface of the wedge, increasing the efficiency of each motor activation or weapon use. The material of these smaller wheels is soft rubber because of the higher friction coefficient between itself and the majority of the viable thermoplastics, compared to the friction coefficient between any two of the viable thermoplastics.

## Subsystem: Power System

For the power system of our battlebot, we will initially plan to use a 9V battery as it is generally light (0.1-0.2 lbs), familiar, and cheap while providing the necessary power for our battlebot. If we find that our drive and weapon will draw too much power, we can pivot to LiPo batteries, which can offer more power through 11.1V or 14.7V options at the expense of size, weight, and cost. Since some of the electronics, including the microcontroller, run at 3V3, step down circuits or chips will be used to step the voltage down to appropriate values.


## Subsystem: Control System

For the main portion of our battlebot’s control system, we are planning to use the ESP32 microcontroller as it has both WiFi and Bluetooth capabilities, plenty of GPIO pins, and available development boards. In particular, we are thinking of using the ESP32-S3-WROOM-1 model as it has a built-in antenna compared to the 1U model and offers more flash space compared to something like the C3 model. We are aiming to use bluetooth in order to communicate with our battlebot, but should we run into difficulties, we can pivot to WiFi as the ESP32 would allow that.

The control system will be responsible for the operation of our robot, including our drive and our weapon activation. In order to fulfill the manual shutdown requirement, we aim to have the robot shutdown if our bluetooth link is lost, but if time allows, we may try to implement a physical shutdown using a keyboard or controller.


# Criterion For Success


This project’s criterion for success are as follows:
- Full functionality of the battlebot, including all operational components and subsystems of the battlebot, through remote communication using either a Bluetooth or WiFi protocol.
- Successful, remote activation and deactivation of the battlebot, without any manual interference
- Successfully and remotely activate the battlebot’s kill-switch mechanism, which should result in all subsystems of the battlebot being disabled or powered off. The kill-switch mechanism must not otherwise affect the battlebot’s functionality or performance in any tangible way.

Automatic Water Bottle Filler

Priyank Jain, Jakub Migus, Abby Mohan

Automatic Water Bottle Filler

Featured Project

# Automatic Water Bottle Filler

Team Members:

- Priyank Jain (priyank3)

- Abby Mohan (ammohan2)

- Jakub Migus (jmigus2)

# Problem

In normal liquid dispensing and water bottle filling systems, the process requires the user’s attention and constant manual activation of the device. This may require the holding of a button, the action of pushing the bottle against a sensor for a specific amount of time, or holding the bottle in front of a sensor until it is full. If the user gets distracted or is unable to provide that attention (blindness or lack of motor function), liquid may spill or the bottle may not be filled enough.

# Solution

Our goal with this project is to make an automatic water bottle filling station. Our device senses when a water bottle is placed underneath it, begins filling the bottle with water once a start button is pressed, determines when the bottle is full and shuts off automatically. After placing the bottle on a platform and pressing a button, the user can walk away knowing their bottle will be filled accurately.

# Solution Components

## Sensing Component

This subsystem utilizes multiple sensors including an ultrasonic sensor to measure the water level and a light-based sensor to determine the height of the bottle.

## Control

This subsystem connects the sensors to the water system. It receives data from the sensors, compares the water level height to the height of the water bottle, then decides to either begin, continue, or stop dispensing water.

## Display/Interface System

An LCD display will show instructions for the user and will display simple messages. A few push buttons will be included for manual filling and selection of desired amount of liquid (ex. Half bottle, full bottle)

## Water System

This subsystem utilizes a water tank attached to a pump and tubing, which transport water to the dispenser.

# Criterion for Success

The device…

- detects a water bottle and accurately measures the height

- monitors the water level in the bottle

- stops filling when a desired water level is reached

If there is no bottle/ the bottle is removed, the device stops filling water.

Project Videos