Project

# Title Team Members TA Documents Sponsor
53 Ultrasound Remote Operated Vehicle
 Gabriel Inojosa
Jamil Yeung
Ted Josephson
 Kaiwen Cao design_document1.pdf
final_paper1.pdf
grading_sheet1.pdf
proposal1.pdf
# Ultrasound Remote Operated Vehicle

Team Members:
- Gabriel Inojosa (gvi2)
- Ted Josephson (tdj4)
- Jamil Yeung (jamilyy2)

# Problem

Submersible remote operated vehicles are often used for the inspection of underwater structures.The use of electromagnetics is predominant in most cases of wireless communication. However, electromagnetic waves of the frequencies typically used for communication in air and free space do not propagate well in water. As a result, submersible ROVs have been developed which communicate with the operator acoustically. However, these are very expensive.

# Solution

We intend to develop a proof of concept for a lower cost acoustically controlled ROV which operates in air, using cheap ultrasonic transducers designed for range finding.
We would like to develop a low-cost method of wireless communication using acoustics for remote control that will fit within the budget of ECE 445. For simplicity of the project, we will use the ECE 110 car as the mechanical basis of our design.

# Solution Components

## Subsystem 1: Transmitter Subsystem

A STM32H7B3RIT6 Microcontroller with a MA40S4S Piezoelectric transducer will be transmitting a modulated control signal using frequency shift keying (FSK) at a carrier frequency of 40 kHz. The packets will be sent using a sequence of data bits that will vary to provide various instructions to the vehicle.
The system will be connected to a laptop drawing 5V power over USB-C and will be communicating over UART using an FTDI FT231XS-R UART to USB converter for debugging purposes.

## Subsystem 2: Receiver Subsystem

Receive ADC on the STM32H7B3RIT6 microcontroller demodulates the output of the RX piezo from the carrier frequency. For debugging purposes, it will also use the FT231XS-R UART to USB converter in order to be read.


## Subsystem 3: Actuator system

A finite state machine will be used to set the vehicle to move forwards, backwards, and allow it to turn. This system will be driving an H bridge to control two DC motors to drive. It will be taking a 9V input from the battery. The STM32 will synchronously drive a MOSFET H-Bridge using a gate driver and a dead time circuit.

## Subsystem 4: Sensor system

Using Serial Peripheral Interface (SPI), the STM32 will communicate with voltage sensors to provide current and voltage readings from the 9V battery discharging on the moving car. Additional sensors (Temperature, etc). May also be included in the SPI bus if the time permits.

## Subsystem 5: Power subsystem

For the moving vehicle, a 9 volt battery will be providing power. This will be stepped down to 3.3 volts using a R-78E3.3-0.5 non-isolated buck DC-DC Converter in order to power the STM32 Microcontroller. 5V power from the USB port will be used for the transmitter board with reverse current protection. A low dropout linear voltage regulator will be used in both systems to keep the voltage at around 3.3V.

# 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.

The power system will draw from a 9V battery to power the microcontroller with 3.3V +- 0.1%

With a microphone and a spectrum analyzer, the transducers will send a modulated FSK signal within a carrier frequency close to 40kHz. Proof of FSK modulation will be provided using oscilloscope screenshots

Upon receiving the modulated signal, a print statement over UART will provide the demodulated instruction packet. Proof of FSK demodulation will be provided using oscilloscope screenshots

The actuator system will successfully turn the car motors forward, reverse, and turn.

The sensor system will be able to properly communicate with the microcontroller over SPI. A varying voltage source will be swept up to 9 volts to prove the measurements of the sensor. Print statements will be provided over UART.

The car with the sensor system will be able to transmit its measurements back to the controller that is remotely positioned. Print statements will be provided over UART

Antweight Battlebot Project

Jeevan Navudu, Keegan Teal, Avik Vaish

Antweight Battlebot Project

Featured Project

# Antweight Battlebot

Team Members:

- Keegan Teal (kteal2)

- Avik Vaish (avikv2)

- Jeevan Navudu (jnavudu2)

# Problem

In order to compete in Professor Gruev’s robot competition, there are many constraints that need to be met, including:

- Maximum weight (2lbs)

- Allowed materials (3D-printed thermoplastics)

- Locomotion system and fighting tool

- Wireless control via Bluetooth or Wifi

The main goal of this competition is to design a Battlebot that is capable of disrupting the functionality of the other Battlebots with our fighting tool while maintaining our own functionality.

# Solution

For the project, we plan to build a battlebot with a custom electronic speed controller (ESC) that can independently control three brushless motors: two for the drive system, and one for the fighting tool. This ESC will be controlled by an STM32 microcontroller, to which we will add a Bluetooth module to connect to it and specify how much power we want to send to each motor. To communicate with our robot, we will use a laptop that can connect to Bluetooth.

# Solution Components

## Vehicle Controller

The main subsystem of the robot will be a combined vehicle control board and ESC. This subsystem will contain an STM32 Microcontroller that will serve as the brain for the whole robot. With this MCU, we’ll be able to flash our whole software package that will be able to control the speed and direction of the robot, the robot’s weapon, and the Bluetooth communication.

## Power Module

This subsystem includes the battery, the voltage regulators/converters needed to power the electronics, and the necessary battery monitoring circuitry. Specifically, for the battery, we will use a 14.8V 4S2P LiPo pack to power all the components. There will also be a voltage short detection circuit for the battery that will shut down the robot in case of a short to ensure safe practices. This subsystem also contains a 5V linear regulator and 3.3V linear regulator to power the low voltage electronics.

## Drivetrain/Powertrain

This subsystem includes the motors and H-bridges needed to control both the wheels and weapon of the robot. The H-bridges will be made with regular N-MOSs that will be controlled by a PWM signal sent from the STM32 MCU. This H-bridge setup will be able to control the voltage and polarity sent to the motors, which will be able to control the speed of the wheels or weapon. This subsystem will also include the mechanical wheels of the robot and actual hardware of the weapon, which will be a spinning object. Since all the wheels and the weapon have the same mechanical motion, they can all use the same hardware and software electronically, with minor adjustments in motor selection and the actual mechanical hardware/peripheral.

## Bluetooth Module

One big requirement for this project is the ability for the robot to be controlled wirelessly via laptop. The STM32 MCU has bluetooth capabilities, and with additional peripheral hardware, the robot will be able to communicate over bluetooth with a laptop. The goal for the laptop is to be able to control the speed, direction, and weapon of the robot wirelessly and also have a display for live telemetry.

## Mechanical Design

The last part of our project would be the mechanical design of the robot chassis and weapon. For the chassis and weapon material, we decided to go with PLA+ as it offers a blend of being strong and robust but not being too brittle. The drive system will be a 2-wheeled tank style drive with one motor controlling each side of the robot. For the weapon, we are looking to utilize a fully 3D-printed drum that will have a 100% infill to maximize the rotational inertia which can lead to bigger impacts.

## Criterion for Success

We would consider our project a success if we are able to communicate with the robot from our computer as in sending throttle and steering commands to the robot, if those commands are then processed on the robots microprocessors and the motors are sent the according power needed to move and behave in the way that we want during a match.

## Alternatives

The most commonly used electronics in current antweight battlebots consist mostly of RC drone parts. We plan to create a very similar ESC to those on the market but it will have an integrated Bluetooth wireless capability as well as telemetry monitoring. We also want to focus on minimizing packaging size to lower weight and increase flexibility as much as possible.

Project Videos