Project

# Title Team Members TA Documents Sponsor
9 Antweight Battlebot
 Allan Gu
Evan Zhao
James Yang
 Michael Gamota design_document1.pdf
final_paper1.pdf
grading_sheet1.pdf
presentation1.pdf
proposal1.pdf
video
# Antweight Battle Bot

Team Members:
- Evan Zhao (evanhz2)
- Allan Gu (allang2)
- James Yang (jamesey2)

# Problem

We must create a Battlebot that weighs less than 2 lbs out of 3D printed materials in order to compete with other battlebots. It must be controlled through Bluetooth or Wi-Fi and be able to be easily shut down. In order to win in the competition, the robot must be robust and capable of destroying the opposing robot, while withstanding damage from other competitors.

# Solution

Our battlebot will be 3D printed with PLA+ and use a vertically spinning disk as our weapon. It will have a 4-wheel drive and be controlled via Bluetooth with an ESP32 microcontroller. This MCU will use PWM to control the H-bridges for motor activation and take in user inputs from a computer.

# Solution Components

## Control System
We plan to use an ESP32 for our MCU, as it has built-in Bluetooth and Wi-Fi capabilities. The battlebot will use Bluetooth to connect and communicate with a computer and a wired controller can be used with the computer to provide more inputs like varying speeds using the joystick. The controller will have a killswitch button for safe shutdown. The ESP32 has a variety of GPIO pins, which can support PWM. This will be used to control the H-bridges for motor speed and direction.

## Power System
For our robot’s power system, we intend to use a 4S LiPo (~14.8 nominal voltage, ~16.8 charged voltage). We chose LiPo as it is a standard in most combat robotics applications for its high power density and ability to discharge lots of charge quickly which is seen a lot in the combat space with high-power weapons and drive motors. Since ESP32 and other modules that we may use do not typically operate at this voltage, we will also need voltage converters and regulators to supply the appropriate power to these sub-modules (typically 3.3V and 5V).

## Movement System
Our combat robot will utilize a four-wheel drive with two brushless or brushed motors on either side of the chassis each driving 2 wheels in a tank-drive configuration. For a brushless configuration, we are considering brushless 1406 motors (https://repeat-robotics.com/buy/repeat-tangent-drive-motors/?attribute_motor-size=1406) that will provide us with plenty of power and torque for a relatively low-cost in weight. A 3-phase inverter will be needed to control the BLDC motors. If we chose brushed motors instead, we would use Repeat Drive Brushed Mk2 (https://repeat-robotics.com/buy/brushed/) which comes with an integrated gearbox and would be simpler to electrically implement than a brushless system at the cost of being less powerful and fast. The motors would be controlled with H-bridges and GPIO from the ESP32.

## Weapon System
The weapon will be some kind of vertically rotating 3D-printed weapon driven by a brushless 2207 Battle Ready Hub Motor (https://repeat-robotics.com/buy/2207-battle-ready-hubmotor/). This motor is known to be reliable and durable for battlebots. Similar to the four-wheel drive motors, we will also need a 3-phase inverter to control the BLDC motor phases.

# Criterion For Success

It would be considered successful if the movement of the robot can be controlled via Bluetooth from a PC and it can function how we would desire within a match such as turning to face the opposing robot and ramming into it with the weapon. The weapon should also be controllable and powerful enough to damage 3D-printed material while maintaining its structural stability.

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