Project

# Title Team Members TA Documents Sponsor
42 FPV Drone Custom Flight Controller
Hulya Goodwin
Jaelynn Abdullah
Muhammad Rabbani
Jason Jung design_document1.pdf
final_paper1.pdf
grading_sheet1.pdf
presentation1.pptx
proposal1.pdf
# Team Members:
Muhammad Rabbani (rabbani3)
Hulya Goodwin (hyg2)
Jaelynn Abdullah (jja8)
# Problem:
Building a custom drone from scratch requires both hardware and software development, particularly in designing an efficient and reliable flight controller. Most off-the-shelf flight controllers come with proprietary firmware, which limits customizability. For advanced applications such as autonomous navigation, swarm coordination, or precision control, users require deeper access to the flight algorithms and hardware integration.
Our goal is to develop a fully functional flight controller to run an FPV drone system. The system is broken down below.
# Solution
We plan to design a custom flight controller that interfaces with drone hardware to provide real-time flight stability and navigation control. The system will consist of a microcontroller-based flight control unit, sensor fusion for IMU data processing, motor control algorithms, and wireless communication for user input.
Our custom firmware will handle:
Sensor data processing (gyroscope, accelerometer, magnetometer)
PID-based flight stabilization
Motor speed control via pulse-width modulation/ESC
Wireless communication for remote control
Constant streaming of the drone’s live camera feed
Manual and autonomous flight modes
Additionally, we will construct a drone frame through 3D printing or PCB design and integrate all components, ensuring a robust and modular design for future improvements.



# Solution Components
## Subsystem 1 – CPU
STM Microcontroller
This subsystem processes sensor data, computes control outputs, and interfaces with the drone’s actuators. We will use Betaflight to handle:
PID (Proportional-Integral-Derivative) control loops for pitch, roll, and yaw stabilization.
Sensor fusion algorithms to accurately estimate the drone’s orientation.
Communication protocols (I2C, SPI, UART) for sensor integration.
The STM32F405 microcontroller is a good candidate due to its real-time processing capabilities


## Subsystem 2 - Sensors
The flight controller must read and process sensor data in real time to maintain stability and control. This subsystem will include:
IMU (Inertial Measurement Unit): Includes an accelerometer and gyroscope to determine the drone’s orientation.
We will likely use the MPU6050 or ICM-20948 for IMU data


## Subsystem 3 - Power
Within our system, the STM32 requires 3.3V and some components require up to 12V. With this, a 4S battery rated for 14.8V and can provide up to 1400mAh will be used to power the Flight Controller, motors, and peripherals. Using a voltage regulator will ensure that the components are getting the correct voltage and a simple voltage divider component will be added to ensure we can send 3.3V for the STM. Since we are using brushless motors, there will not be a need for an H-Bridge. The battery specifically would be a BetaFPV 4S 450mAh 75C.


##Subsystem 4 - Telemetry System
We will purchase a radio transmitter (LiteRadio 3 SE Radio Transmitter from BETAFPV) in the shape of a game controller to allow us to control the movement of the drone. It uses Tx protocol ExpressLRS to transmit the user's input to the radio receiver. The radio receiver will be an ELRS Nano Receiver (from BETAFPV) with a receiver protocol CRSF to communicate between the receiver and the FC. The FC then communicates with the KISS 24A ESC that will be using ESC protocol Dshot to control the speed of the motors.


## Subsystem 5 - Physical Drone
The physical drone will be made by us. This frame will either be 3D printed and sanded down for aerodynamics or made of PCB material that’s insulated and separated from the flight controller PCB in case of a crash. It will be an X-Frame Quadcopter with a larger center to place the FC on. If our frame is not flyable, then there are cheap drone frames we can purchase as well. For the motors, we will probably stick with the same brand and use BetaFPV 1404 3800KV.


## Subsystem 6 - Camera + Goggles
For using analog communication, a Caddx Ant Lite or a Runcam Nano 3 would be useful considering we are using a MAX7456 OSD. To broadcast this device, we would need a plug in receiver for the phone, however, the latency would be an issue. For staying within our budget, a Eachine ROTG02, however, has a latency near 100ms. We can utilize apps online (such as GoFPV and FPViewer) but if time allows, we can make our own interface. For the phone, we will create a housing similar to Google's Cardboard.




## Criterion For Success
We will demonstrate a working flight controller that has full control over our various subsystems: We receive live data from our sensors. We receive live video from our camera. We have complete control over our power subsystem and various motors to achieve synchronous motion. Our micro controller has our custom/modified program to completely analyze our sensor data to control our motors in response to our orientation and inputted controls.










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