Project

# Title Team Members TA Documents Sponsor
51 BTTL BOT PROPOSAL
 Aditya Saxena
Laksh Sharma
 Xiyue Zhu
# Dual Smash: Ant-Weight Battle Bot

Team Members:

-Aditya Saxena (saxena11)

-Laksh Sharma (lsharma2)

# Problem

This is our team's entry for the Fall 2026 ECE 445 Battlebots competition. We will build a sub-2 lb combat robot that can be controlled wirelessly from a laptop and compete against other robots in the arena.

Most battlebot designs use a spinning weapon, wedge, or single attacking mechanism. Our idea is to use two side-mounted hammers that swing horizontally. The hammers can be controlled separately, or both can be activated at the same time in a mode we call "Dual Smash." The goal is to use the two hammers to strike, push, or destabilize an opposing robot while still keeping the robot responsive and easy to control.


# Solution

We will build a 3D-printed ant-weight battlebot controlled by an ESP32-S3 through WiFi. The robot will use differential drive with two brushed DC gearmotors, allowing it to move forward, backward, and turn in place.

The main fighting system will consist of two side-mounted horizontal hammer arms. Each hammer will be driven by its own motor or high-torque actuator. The driver will be able to activate the left hammer, right hammer, or both simultaneously. Activating both hammers together will be called Dual Smash.

The robot will also contain an onboard camera and time-of-flight sensors. The camera will provide a live video feed to the driver's laptop, while the ToF sensors will provide distance information about nearby robots or obstacles. This information will be displayed in the driver interface and used to help position the robot before attacking.

A custom PCB will contain the ESP32-S3, motor-control circuitry, sensor connections, power regulation, and safety circuitry. The robot will be powered using a 2S LiPo battery.

# Solution Components

## Subsystem 1: Camera and Driver Interface

- Hardware: ESP32-S3-WROOM-1 microcontroller and OV5640 camera module connected through the ESP32-S3 camera interface.

- Software: The ESP32-S3 will capture and transmit camera frames over WiFi to a laptop. The laptop interface will display the live camera feed, robot status, ToF measurements, and controls for movement and the two hammer weapons.

The driver interface will allow separate commands for the left hammer, right hammer, and Dual Smash mode.

## Subsystem 2: Time-of-Flight Sensing

- Hardware: Four VL53L1X time-of-flight sensors positioned around the robot, with sensors facing the front, rear, left, and right sides.

- Software: The ESP32-S3 will configure and read each ToF sensor over I2C. Since the sensors share the same default I2C address, their XSHUT pins will be used during startup to assign separate addresses.

The distance measurements will be transmitted to the driver laptop and displayed alongside the camera feed. The sensor data will help the driver determine when an opposing robot is within range of the side hammers.

## Subsystem 3: Drive and Dual Smash Weapon System

- Hardware: Two brushed DC gearmotors will provide differential drive. A TB6612FNG dual H-bridge motor driver will control the drive motors.

The weapon system will contain two independently controlled side-mounted horizontal hammer arms. Each hammer will be connected to its own high-torque motor or actuator through a mechanical linkage. The final motor and gear ratio will be selected based on the required hammer speed, torque, and robot weight. Motor-driver circuitry will allow the ESP32-S3 to control the direction and activation of each hammer.

- Software: The ESP32-S3 will generate PWM and direction signals for the drivetrain and hammer actuators. The driver will be able to activate either hammer individually or activate both at the same time using Dual Smash.

The software will also enforce a cooldown or reset period between hammer activations so that the mechanism has time to return to its starting position before another strike.

A communication-loss safety system will disable the drive and weapon motors if the WiFi connection to the driver laptop is lost.

## Subsystem 4: Power System

- Hardware: A 2S LiPo battery will provide power to the drivetrain, hammer motors, and electronics. The battery capacity will be selected after measuring the final current requirements and checking the total robot weight.

Voltage regulation will provide the required voltage rails for the ESP32-S3, camera, ToF sensors, and supporting electronics. The custom PCB will also contain decoupling capacitors, power distribution, motor connections, and protection circuitry.

A MOSFET-based motor cutoff and manual emergency stop will be included so that power to the drivetrain and hammer system can be disabled quickly.

- Software: The ESP32-S3 will monitor communication status and place the robot into a safe state if the wireless connection is lost. Motor commands will default to zero during startup, connection loss, or emergency shutdown.

# Criterion For Success

1. The completed robot will weigh less than 2 lb, including the battery, PCB, camera, sensors, drivetrain, and both hammer mechanisms.
2. The robot will respond correctly to forward, reverse, left, and right movement commands from the laptop during repeated testing.
3. The camera system will provide a continuous live video feed to the driver's laptop during a full 2-minute match.
4. All four VL53L1X sensors will initialize correctly and provide distance measurements that are consistent with measured physical distances.
5. The left and right hammer mechanisms will each complete at least 20 consecutive strike and reset cycles without mechanical or electrical failure.
6. Dual Smash will activate both side hammers together, with both hammer movements beginning within 100 ms of each other.
7. The robot will be able to strike or destabilize another ant-weight robot using either an individual hammer or Dual Smash.
8. Drive and weapon power will be disabled within 500 ms of losing the WiFi control connection.
9. The robot will remain controllable while simultaneously transmitting camera and ToF data to the driver laptop.
10. The complete system will operate continuously for the duration of a full 2-minute match without requiring a controller reset.

Disclaimer: We used AI to help format and word this document.

Covert Communication Device

Ahmad Abuisneineh, Srivardhan Sajja, Braeden Smith

Covert Communication Device

Featured Project

**Partners (seeking one additional partner)**: Braeden Smith (braeden2), Srivardhan Sajja (sajja3)

**Problem**: We imagine this product would have a primary use in military/law enforcement application -- especially in dangerous, high risk missions. During a house raid or other sensitive mission, maintaining a quiet profile and also having good situational awareness is essential. That mean's that normal two way radios can't work. And alternatives, like in-ear radios act as outside->in communication only and also reduce the ability to hear your surroundings.

**Solution**: We would provide a series of small pocketable devices with long battery that would use LoRa radios to provide a range of 1-5 miles. They would be rechargeable and have a single recessed soft-touch button that would allow someone to find it inside of pockets and tap it easily. The taps would be sent in real-time to all other devices, where they would be translated into silent but noticeable vibrations. (Every device can obviously TX/RX).

Essentially a team could use a set of predetermined signals or even morse code, to quickly and without loss of situational awareness communicate movements/instructions to others who are not within line-of-sight.

The following we would not consider part of the basic requirements for success, but additional goals if we are ahead of schedule:

We could also imagine a base-station which would allow someone using a computer to type simple text that would be sent out as morse code or other predetermined patterns. Additionally this base station would be able to record and monitor the traffic over the LoRa channels (including sender).

**Solutions Components**:

- **Charging and power systems**: the device would have a single USB-C/Microusb port that would connect to charging circuitry for the small Lithium-ion battery (150-500mAh). This USB port would also connect to the MCU. The subsystem would also be responsible to dropping the lion (3.7-4.2V to a stable 3.3V logic level). and providing power to the vibration motor.

- **RF Communications**: we would rely on externally produced RF transceivers that we would integrate into our PCB -- DLP-RFS1280, https://www.sparkfun.com/products/16871, https://www.adafruit.com/product/3073, .

-**Vibration**: We would have to research and source durable quiet, vibration motors that might even be adjustable in intensity

- **MCU**: We are likely to use the STM32 series of MCU's. We need it to communicate with the transceiver (probably SPI) and also control the vibration motor (by driving some transistor). The packets that we send would need to be encrypted (probably with AES). We would also need it to communicate to a host computer for programming via the same port.

- **Structural**: For this prototype, we'd imagine that a simple 3d printed case would be appropriate. We'd have to design something small and relatively ergonomic. We would have a single recessed location for the soft-touch button, that'd be easy to find by feel.

**Basic criterion for success:** We have at least two wireless devices that can reliably and quickly transfer button-presses to vibrations on the other device. It should operate at at *least* 1km LOS. It should be programmable + chargeable via USB. It should also be relatively compact in size and quiet to use.

**Additional Success Criterion:** we would have a separate, 3rd device that can stay permanently connected to a computer. It would provide some software that would be able to send and receive from the LoRa radio, especially ASCII -> morse code.