Project

# Title Team Members TA Documents Sponsor
51 BTTL BOT PROPOSAL
 Aditya Saxena
Laksh Sharma
 Xiyue Zhu design_document1.pdf
proposal1.pdf
# 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.

Interactive Proximity Donor Wall Illumination

Sungmin Jang, Anita Jung, Zheng Liu

Interactive Proximity Donor Wall Illumination

Featured Project

Team Members:

Anita Jung (anitaj2)

Sungmin Jang (sjang27)

Zheng Liu (zliu93)

Link to the idea: https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=27710

Problem:

The Donor Wall on the southwest side of first floor in ECEB is to celebrate and appreciate everyone who helped and donated for ECEB.

However, because of poor lighting and color contrast between the copper and the wall behind, donor names are not noticed as much as they should, especially after sunset.

Solution Overview:

Here is the image of the Donor Wall:

http://buildingcampaign.ece.illinois.edu/files/2014/10/touched-up-Donor-wall-by-kurt-bielema.jpg

We are going to design and implement a dynamic and interactive illuminating system for the Donor Wall by installing LEDs on the background. LEDs can be placed behind the names to softly illuminate each name. LEDs can also fill in the transparent gaps in the “circuit board” to allow for interaction and dynamic animation.

And our project’s system would contain 2 basic modes:

Default mode: When there is nobody near the Donor Wall, the names are softly illuminated from the back of each name block.

Moving mode: When sensors detect any stimulation such as a person walking nearby, the LEDs are controlled to animate “current” or “pulses” flowing through the “circuit board” into name boards.

Depending on the progress of our project, we have some additional modes:

Pressing mode: When someone is physically pressing on a name block, detected by pressure sensors, the LEDs are controlled to

animate scattering of outgoing light, just as if a wave or light is emitted from that name block.

Solution Components:

Sensor Subsystem:

IR sensors (PIR modules or IR LEDs with phototransistor) or ultrasonic sensors to detect presence and proximity of people in front of the Donor Wall.

Pressure sensors to detect if someone is pressing on a block.

Lighting Subsystem:

A lot of LEDs is needed to be installed on the PCBs to be our lighting subsystem. These are hidden as much as possible so that people focus on the names instead of the LEDs.

Controlling Subsystem:

The main part of the system is the controlling unit. We plan to use a microprocessor to process the signal from those sensors and send signal to LEDs. And because the system has different modes, switching between them correctly is also important for the project.

Power Subsystem:

AC (Wall outlet; 120V, 60Hz) to DC (acceptable DC voltage and current applicable for our circuit design) power adapter or possible AC-DC converter circuit

Criterion for success:

Whole system should work correctly in each mode and switch between different modes correctly. The names should be highlighted in a comfortable and aesthetically pleasing way. Our project is acceptable for senior design because it contains both hardware and software parts dealing with signal processing, power, control, and circuit design with sensors.

Project Videos