Project

# Title Team Members TA Documents Sponsor
53 Ultrasound Remote Operated Vehicle
 Gabriel Inojosa
Jamil Yeung
Ted Josephson
 Kaiwen Cao 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

Cloud-controlled quadcopter

Anuraag Vankayala, Amrutha Vasili

Cloud-controlled quadcopter

Featured Project

Idea:

To build a GPS-assisted, cloud-controlled quadcopter, for consumer-friendly aerial photography.

Design/Build:

We will be building a quad from the frame up. The four motors will each have electronic speed controllers,to balance and handle control inputs received from an 8-bit microcontroller(AP),required for its flight. The firmware will be tweaked slightly to allow flight modes that our project specifically requires. A companion computer such as the Erle Brain will be connected to the AP and to the cloud(EC2). We will build a codebase for the flight controller to navigate the quad. This would involve sending messages as per the MAVLink spec for sUAS between the companion computer and the AP to poll sensor data , voltage information , etc. The companion computer will also talk to the cloud via a UDP port to receive requests and process them via our code. Users make requests for media capture via a phone app that talks to the cloud via an internet connection.

Why is it worth doing:

There is currently no consumer-friendly solution that provides or lets anyone capture aerial photographs of them/their family/a nearby event via a simple tap on a phone. In fact, present day off-the-shelf alternatives offer relatively expensive solutions that require owning and carrying bulky equipment such as the quads/remotes. Our idea allows for safe and responsible use of drones as our proposed solution is autonomous, has several safety features, is context aware(terrain information , no fly zones , NOTAMs , etc.) and integrates with the federal airspace seamlessly.

End Product:

Quads that are ready for the connected world and are capable to fly autonomously, from the user standpoint, and can perform maneuvers safely with a very simplistic UI for the common user. Specifically, quads which are deployed on user's demand, without the hassle of ownership.

Similar products and comparison:

Current solutions include RTF (ready to fly) quads such as the DJI Phantom and the Kickstarter project, Lily,that are heavily user-dependent or user-centric.The Phantom requires you to carry a bulky remote with multiple antennas. Moreover,the flight radius could be reduced by interference from nearby conditions.Lily requires the user to carry a tracking device on them. You can not have Lily shoot a subject that is not you. Lily can have a maximum altitude of 15 m above you and that is below the tree line,prone to crashes.

Our solution differs in several ways.Our solution intends to be location and/or event-centric. We propose that the users need not own quads and user can capture a moment with a phone.As long as any of the users are in the service area and the weather conditions are permissible, safety and knowledge of controlling the quad are all abstracted. The only question left to the user is what should be in the picture at a given time.

Project Videos