Project

# Title Team Members TA Documents Sponsor
10 3D Printed Antweight Battlebot
Brian Pau
Don Lazatin
Shashank Sangireddy
Jason Jung design_document1.pdf
final_paper1.pdf
grading_sheet1.pdf
proposal1.pdf
video
# Antweight Battlebot Competition Request for Approval

Team Members:
- Don Lazatin (dlazat2)
- Shashank Sangireddy (ssangi2)
- Brian Pau (bnpau2)

# Problem


For our project, we plan on competing in Professor Gruev’s Antweight Battlebot Competition. In order to do so, our Battlebot must adhere to several limitations and requirements. The requirements are listed below

- Battlebot must be less than 2lbs
- Battlebot must be constructed using 3D printed materials
- Battlebot must have a PCB controlled via PC through Bluetooth or Wifi
- Battlebot must have an attached fighting tool that will be activated by the motors
- Battlebot must have a way of easy manual shutdown and automatic shutdown
- Battlebot must adhere to in-competition rules

Our overall goal for this project is to design, build and program a Battlebot object that is capable of disabling competing Battlebot objects with our fighting tool.


# Solution

We plan to build a battlebot with a destabilizing wedge as our fighting tool. We’ve decided to 3D print various parts of the battlebot’s body, such as the chassis and wheels. We will incorporate at least two different kinds of thermoplastic, PLA+ and PETG, according to their relative strengths.
We’ve decided to go with a ESP32-S3-WROOM-1 for our microcontroller, which is responsible for controlling the connected motors. We chose this microcontroller for its superior flash memory space and built-in antenna for Bluetooth communication. In the event that a Bluetooth based protocol is not viable for our design, this microcontroller will allow us to pivot over to a WiFi based protocol.
There will be at least 3 separate motors in use: one motor may be a brushless motor used for activating the fighting tool, and the other two may be DC-powered micromotors that will be used to activate the battlebot’s wheels for mobility. This set of wheels will be driven by H bridge, implemented using N-channel MOSFETs, which would enable precise control of forward-backward movement.
The battlebot will be powered using a rechargeable 9V battery, with current-restricting circuit components such as step-down circuitry or chips incorporated to protect the rest of the circuit from excess voltage.


# Solution Components

## Subsystem: Chassis

The chassis of a battlebot should be thought of as the body and structural base for a competing battlebot. Our chassis will be 3D-printed out of PLA+ filament to ensure a strong armor and follow the weighting guideline for the competition. The chassis will house and protect the main circuit, motors, weaponry, and power source for our device.

Our chassis will have a symmetrically horizontal structure so that if our battlebot is flipped over in competition, it will still have the same operational effectiveness as it would on its original side. We plan on constructing a square-like bodily structure so that there would be no weak side of the chassis for other bots to target. We plan on covering all the electronic components within the body to ensure safety and protection for the internal core of the battlebot.

## Subsystem: Drive System

For our battlebot’s drive system, we plan on producing a 2-wheel drive mechanism with the front of the chassis (weapon) dragging across the floor on top of powerless mini wheels. For the tire treads, we plan on looking into rubber-like materials in order for our battlebot’s movement to be controllable and smooth during operations.

For our battlebot’s drive motor, we plan on using a type of DC-powered micro motor. We are choosing to propose this motor as it would be ideal for a battlebot competition environment. With these types of motors, they significantly reduce the motor’s rotational speed and significantly increase the torque. This is ideal because we are not in need of much speed in a competition arena. Rather, the increase in power output would be more beneficial.

## Subsystem: Weapon System

The fighting tool will be a wedge, designed to lift the opposing battlebot with the intent to destabilize, disorient, and ultimately flip the opponent over. It will be located in front of the battlebot, and will consist of at least 30% of the battlebot’s weight. This amount of mass, combined with motor activation for high amounts of power should result in an effective destabilizing fighting tool, fit to render the opposing battlebot unable to function.
The wedge “weapon” will also be fitted with small, free-moving rubber wheels on its outer surface. The purpose of these wheels is to guide the opposing battlebot’s chassis along the surface of the wedge, increasing the efficiency of each motor activation or weapon use. The material of these smaller wheels is soft rubber because of the higher friction coefficient between itself and the majority of the viable thermoplastics, compared to the friction coefficient between any two of the viable thermoplastics.

## Subsystem: Power System

For the power system of our battlebot, we will initially plan to use a 9V battery as it is generally light (0.1-0.2 lbs), familiar, and cheap while providing the necessary power for our battlebot. If we find that our drive and weapon will draw too much power, we can pivot to LiPo batteries, which can offer more power through 11.1V or 14.7V options at the expense of size, weight, and cost. Since some of the electronics, including the microcontroller, run at 3V3, step down circuits or chips will be used to step the voltage down to appropriate values.


## Subsystem: Control System

For the main portion of our battlebot’s control system, we are planning to use the ESP32 microcontroller as it has both WiFi and Bluetooth capabilities, plenty of GPIO pins, and available development boards. In particular, we are thinking of using the ESP32-S3-WROOM-1 model as it has a built-in antenna compared to the 1U model and offers more flash space compared to something like the C3 model. We are aiming to use bluetooth in order to communicate with our battlebot, but should we run into difficulties, we can pivot to WiFi as the ESP32 would allow that.

The control system will be responsible for the operation of our robot, including our drive and our weapon activation. In order to fulfill the manual shutdown requirement, we aim to have the robot shutdown if our bluetooth link is lost, but if time allows, we may try to implement a physical shutdown using a keyboard or controller.


# Criterion For Success


This project’s criterion for success are as follows:
- Full functionality of the battlebot, including all operational components and subsystems of the battlebot, through remote communication using either a Bluetooth or WiFi protocol.
- Successful, remote activation and deactivation of the battlebot, without any manual interference
- Successfully and remotely activate the battlebot’s kill-switch mechanism, which should result in all subsystems of the battlebot being disabled or powered off. The kill-switch mechanism must not otherwise affect the battlebot’s functionality or performance in any tangible way.

Master Bus Processor

Clay Kaiser, Philip Macias, Richard Mannion

Master Bus Processor

Featured Project

General Description

We will design a Master Bus Processor (MBP) for music production in home studios. The MBP will use a hybrid analog/digital approach to provide both the desirable non-linearities of analog processing and the flexibility of digital control. Our design will be less costly than other audio bus processors so that it is more accessible to our target market of home studio owners. The MBP will be unique in its low cost as well as in its incorporation of a digital hardware control system. This allows for more flexibility and more intuitive controls when compared to other products on the market.

Design Proposal

Our design would contain a core functionality with scalability in added functionality. It would be designed to fit in a 2U rack mount enclosure with distinct boards for digital and analog circuits to allow for easier unit testings and account for digital/analog interference.

The audio processing signal chain would be composed of analog processing 'blocks’--like steps in the signal chain.

The basic analog blocks we would integrate are:

Compressor/limiter modes

EQ with shelf/bell modes

Saturation with symmetrical/asymmetrical modes

Each block’s multiple modes would be controlled by a digital circuit to allow for intuitive mode selection.

The digital circuit will be responsible for:

Mode selection

Analog block sequence

DSP feedback and monitoring of each analog block (REACH GOAL)

The digital circuit will entail a series of buttons to allow the user to easily select which analog block to control and another button to allow the user to scroll between different modes and presets. Another button will allow the user to control sequence of the analog blocks. An LCD display will be used to give the user feedback of the current state of the system when scrolling and selecting particular modes.

Reach Goals

added DSP functionality such as monitoring of the analog functions

Replace Arduino boards for DSP with custom digital control boards using ATmega328 microcontrollers (same as arduino board)

Rack mounted enclosure/marketable design

System Verification

We will qualify the success of the project by how closely its processing performance matches the design intent. Since audio 'quality’ can be highly subjective, we will rely on objective metrics such as Gain Reduction (GR [dB]), Total Harmonic Distortion (THD [%]), and Noise [V] to qualify the analog processing blocks. The digital controls will be qualified by their ability to actuate the correct analog blocks consistently without causing disruptions to the signal chain or interference. Additionally, the hardware user interface will be qualified by ease of use and intuitiveness.

Project Videos