Project

# Title Team Members TA Documents Sponsor
41 Antwieght Battle Bot Project Proposal
Anthony Shen
Batu Yesilyurt
Praman Rai
Sanjana Pingali proposal1.pdf
# Antweight Battlebot

Batu Yesilyurt (batuy2)

Praman (pramanr2)

Anthony (arshen2)

# Problem

Eight teams will compete with their own battlebots in a tournament. The antweight battlebots have the following constraints: Less than 2 lbs, 3D printed plastics, custom PCB that connects via bluetooth to microcontroller, motor or pneumatic fighting tool, and easy manual/automatic shutdown.

# Solution

Our plan is to be able to control and prevent the opposing robot from moving to win by decision. Controlling the opposing robot is an effective yet simple way to earn points. We plan on having arms that extend out and grab the opposing battlebot, preventing it from moving.The biggest challenge that we predict we will face is the 2 lb weight constraint. This might prevent the use of any additional features such as weapons to damage the opposing battlebot when we have it under control.

# Solution Components

## Materials

The primary purpose of our robot will be to control the enemy, this means that our robot needs to be resistant to their attacks. Most battlebots will use kinetic weapons, so we plan on using PETG because of its impact resistance.

## Control System

The controls will be managed and powered by an STM32 microcontroller, which will direct the 3 DC motors (2 drivetrain and 1 weapon) while also utilizing its embedded wireless communication. The bluetooth module will interface with an external controller (likely PC) and will enable low latency wireless control. The microcontroller will also leverage GPIO and PWM to enable precise speed control and directional control for the motors. Furthermore, we will implement an H-bridge for additional control and stabilization.

## Power System

We plan on using a 12v LiPO battery because it would provide us with lots of power for our weapons system while also being light.

## Movement System

We plan on using brushless motors to operate 2 wheels on either side of the battlebot. Our winning condition will involve pushing and controlling the other team's robot so higher torque will be more preferred over high speed motors to be able to move around the other team's battlebot. To save weight we will use a high torque motor with a fixed gear ratio. We will sacrifice speed for torque. We will also try to distribute the weight of the robot components over the wheels to maximize downforce for grip.

## Weapon System

For our weapon, we plan to utilize 2 arms that would wrap around the other robot to control and prevent it from moving. These arms will utilize a big portion of the weight budget in order to make sure they are strong enough to restrain the other robot and also take hits when not deployed.

# Criterion For Success

For a successful project, the robot should complete 3 goals. First is the remote control of the robot through bluetooth or wifi from the PC. Second the robot should automatically disable in the event the remote connection is disabled. Third the robot should drive and operate the weapon to a functional degree

Prosthetic Control Board

Caleb Albers, Daniel Lee

Prosthetic Control Board

Featured Project

Psyonic is a local start-up that has been working on a prosthetic arm with an impressive set of features as well as being affordable. The current iteration of the main hand board is functional, but has limitations in computational power as well as scalability. In lieu of this, Psyonic wishes to switch to a production-ready chip that is an improvement on the current micro controller by utilizing a more modern architecture. During this change a few new features would be added that would improve safety, allow for easier debugging, and fix some issues present in the current implementation. The board is also slated to communicate with several other boards found in the hand. Additionally we are looking at the possibility of improving the longevity of the product with methods such as conformal coating and potting.

Core Functionality:

Replace microcontroller, change connectors, and code software to send control signals to the motor drivers

Tier 1 functions:

Add additional communication interfaces (I2C), and add temperature sensor.

Tier 2 functions:

Setup framework for communication between other boards, and improve board longevity.

Overview of proposed changes by affected area:

Microcontroller/Architecture Change:

Teensy -> Production-ready chip (most likely ARM based, i.e. STM32 family of processors)

Board:

support new microcontroller, adding additional communication interfaces (I2C), change to more robust connector. (will need to design pcb for both main control as well as finger sensors)

Sensor:

Addition of a temperature sensor to provide temperature feedback to the microcontroller.

Software:

change from Arduino IDE to new toolchain. (ARM has various base libraries such as mbed and can be configured for use with eclipse to act as IDE) Lay out framework to allow communication from other boards found in other parts of the arm.