Project

# Title Team Members TA Documents Sponsor
9 Ant Weight 3-D Printed BattleBot
John Tian
Mig Umnakkittikul
Yanhao Yang
 Gayatri Chandran design_document1.pdf
final_paper2.pdf
photo1.png
photo2.jpg
presentation1.pdf
proposal1.pdf
video
# Ant Weight 3D Printed BattleBot Competition
Team Members

Yanhao Yang (yanhaoy2)

Yunhan Tian (yunhant2)

Mig Umnakkittikul (sirapop3)

# Problem

We will design a 3-D printed BattleBot to attend the competition instructed by Professor Gruev. To attend the competition, we will need to meet the following requirements:

- BattleBot must be under 2 lbs.
- BattleBot must be made only of these materials: PET, PETG, ABS, or PLA/PLA+.
- BattleBot must be controlled by PC via Bluetooth or Wi-Fi.
- BattleBot must have a custom PCB that will hold a microprocessor, Bluetooth or Wi-Fi receiver, and H-bridge for motor control.
- BattleBot must have a fighting tool activated by a motor.
- BattleBot must have an easy manual shutdown and automatic shutdown with no RF link.
- BattleBot will adhere to the rules on the NRC website.

Our overall goal is to design, code, and build a war robot capable of thriving in the robot battle competition.

# Solution

We will build a 2-lb, 3-D printed BattleBot with a front-hinged lifting wedge (shovel) as the weapon to flip and destabilize other robots. The main structure will be ABS for toughness, PLA for non-critical connectors, and PETG around the power system and microcontroller for heat resistance. Control is via PC over Wi-Fi or Bluetooth using an ESP32 microcontroller.The bot will have at least three motors:Two DC-powered motors to control the robot's wheels for mobility. One geared lifter motor for the shovel, controlled through H-bridge drivers.

# Solution Components

## Microprocessor

We will use the ESP32-S3-WROOM-1-N16 for our BattleBot because it combines built-in Wi-Fi and Bluetooth, eliminating the need for separate modules. Its dual-core processor and ample RAM/flash provide sufficient power to handle motor control, PWM generation, weapon actuation, and sensor processing simultaneously. Its weight (6.5 g) is ideal for a 2-lb bot, and it supports many peripherals.

## Attack Mechanism

To attack, destabilize, and flip opponent bots, we will use a front-hinged lifting wedge (“shovel”) as our primary weapon. The wedge will be 3-D printed with PETG for impact resistance, reinforced at hinge and linkage points to withstand stress. It will span about 50–70% of the bot’s width and feature a low, angled tip to slide under opponents effectively. A small, geared lifter motor will actuate the wedge through a lever linkage, which amplifies the torque from the motor to lift a 2-lb target.

## Mobility System

We will use four small wheels (2.25’’), with the two rear wheels powered by high-torque 600 RPM, 12V DC motors. The smaller wheels lower the ride height of the bot, giving it a lower center of gravity, which improves stability during combat and reduces the chance of being flipped, while still providing solid ground traction. The motors strike a good balance between speed and torque, offering sufficient pushing power to maneuver our heavily armored bot effectively.

## Power System

We will use Lithium Polymer (LiPo) batteries, 4S 14.8V 750 mAh, as the higher voltage may be required for the weaponry. LiPo batteries are significantly lighter than NiCd, provide more power, and save space.

Additionally, we will integrate a motor current sensor (e.g., INA219 or ACS712) into the motor driver circuits to monitor current draw. The ESP32 will read these values in real-time, allowing us to detect stalling conditions and activate manual/automatic shutdown to protect motors and electronics.

## Bot Structure Materials

We will use ABS for the main bot structure, as it offers sufficient strength and a good balance between durability and printability. PLA will be used for general-purpose parts, such as inner connection pieces, where high strength is not required. Finally, PETG will be used around the power system and microprocessor to provide additional heat resistance.

# Criterion for Success

The project will be considered successful if:

- The BattleBot can be fully controlled remotely by PC, including movement and wedge activation.
- The wedge lifter and drive motors operate reliably, capable of destabilizing or flipping a 2-lb opponent.
- Manual and automatic shutdowns function correctly, independent of wireless communication.

Schnorr Protocol Key Fob

Michael Gamota, Vasav Nair, Pedro Ocampo

Featured Project

# Schnorr Identification Protocol Key Fob

Team Members:

- Michael Gamota (mgamota2)

- Vasav Nair (vasavbn2)

- Pedro Ocampo (pocamp3)

# Problem

Current car fobs are susceptible to different types of attacks. Rolling jam attacks are one of such attacks where an attacker jams and stores a valid "unlock" signal for later. Cars with passive keys/cards can be stolen using relay attacks. Since a car can be the most expensive item someone owns, it is unreasonable to allow people to steal them so discreetly by hacking the fob/lock combo.

# Solution

By leveraging public key cryptography, specifically the Schnorr identification protocol, it is possible to create a key fob which is not susceptible to either attack (rolling jam and relay) and also gives no information about the private key of the fob if the signal were to be intercepted.

# Solution Components

# Key Fob

## Subsystem 1

Random number generation - We will use a transistor circuit to generate random numbers. This is required by the Schnorr protocol to ensure security.

## Subsystem 2

Microcontroller - The MCU will run all the computation to calculate the messages. We will likely use an ATtiny MCU so we can use the Arduino IDE for programming. However, some group members have experience with the STM32 family so that is another option.

## Subsystem 3

Power - We plan on using either a 5V battery or 3.3V battery with a boost converter to power the fob.

## Subsystem 4

Wireless Communication - We plan on using the 315 MHz frequency band which is currently used by some car fobs. We will need a transmitter and receiver, since the protocol is interactive.

# Lock

## Subsystem 1

Random number generation - We will use a transistor circuit to generate random numbers. This is required by the Schnorr protocol to ensure security.

## Subsystem 2

Microcontroller - This MCU will also run all the computation to calculate the messages. We will likely use an ATtiny MCU so we can use the Arduino IDE for programming. However, some group members have experience with the STM32 family so that is another option. This MCU will need to have PWM output to control the lock.

## Subsystem 3

Linear Actuator - We plan on using a linear actuator as a deadbolt lock for demonstration purposes.

## Subsystem 4

Wireless Communication - We plan on using the 315 MHz frequency band which is currently used by some car fobs. We will need a transmitter and receiver, since the protocol is interactive.

## Subsystem 5

Power - This subsystem will also likely require 5V, but power sourcing is not an issue since this system would be connected to the car battery. During a demo I would be acceptable to have this plugged into a power supply or a barrel jack connector from an AC-DC converter.

# Criterion For Success

Describe high-level goals that your project needs to achieve to be effective. These goals need to be clearly testable and not subjective.

Our first criteria for success is a reasonably sized fob. There is some concern about the power storage and consumption of the fob.

The next criteria for success is communication between the fob and the lock. This will be the first milestone in our design. We will need to have a message sent from one MCU that is properly received by the other, we can determine this in the debug terminal.

Once we are sure that we can communicate between the fob and the lock, we will implement the Schnorr protocol on the two systems, where the fob will act as the prover and the lock as the verifier. If the Schnorr signature implementation is correct, then we will always be able to unlock the lock using the fob whose public key is associated with full privileges.

Project Videos