QUADCOPTER

QuadCopter F401 · Rev B

A custom four-layer flight-controller PCB

STM32F401CCU6 processing, BMI270 inertial sensing, BMP390L pressure sensing and a BMM350 magnetometer — with four ESC signal outputs, two UARTs, USB-C and SWD in a 55.88 mm square board.

Current milestone: prototype hardware CAD release. The board is fully routed and its configured DRC/ERC checks pass. Firmware integration, first-board bring-up and flight testing remain to be completed. The image is a CAD render; SW3 is not modeled.

Hardware guide · Connections · Firmware integration · Engineering changes · Fabrication instructions

What this project does

The PCB brings the sensing, processing and low-voltage interfaces of a small quadcopter flight controller onto one board. It is intended to read motion and environmental sensors, communicate with external receiver/telemetry peripherals, and send commands to four separate ESCs once the required firmware is implemented.

This is a flight-controller board, not a motor power-distribution board or an ESC. It contains no radio receiver or GPS module. Its 5 V input requires a regulated BEC; it must not be connected directly to a flight battery.

Release status

The DRC report, ERC report and validation summary with source hashes provide the evidence. No individual DRC exclusions were added. Inherited ignored rule categories and the J1 local fabrication rule are documented in the engineering notes. These are CAD results, not measured hardware or flight results.

Hardware at a glance

Board views

Top: components and interfaces	Bottom: labels and orientation

Assembly drawing · Top routing view · Bottom routing view · Schematics

The renders use actual project geometry. Custom model alignment is illustrative rather than a certified mechanical enclosure model; standard KiCad 10 3D libraries are needed for a complete local preview.

Electrical design

Regulated 5 V only. SW3 selects the BEC input or diode-isolated USB power. U5 supplies the 3.3 V rail, while U7 supplies the BMM350's 1.8 V core. BMM350 VDDIO and auxiliary-bus pull-ups stay at 3.3 V to match the BMI270. PA0 monitors the selected 5 V rail through a 10 kΩ / 10 kΩ divider.

USB-C uses separate 5.1 kΩ CC pull-downs, both data-contact orientations, grounded shield pads and USBLC6-2P6 protection. SWD remains the primary programming/recovery interface. PA9 is allocated to UART TX, so application firmware must account for unavailable USB VBUS sensing on that pin.

The inner ground plane provides a return path; In2.Cu distributes power. The BMM350 has local core/I/O decoupling and its specified 2.2 µF nonmagnetic CRST capacitor. The MCU analog rail is filtered with a ferrite bead. C2/C3 and R5 still need oscillator startup/drive-level qualification on real hardware.

See hardware details for the power path, PCB stack, sensors, protection and fabrication constraints.

External connections

TX/RX labels are from the controller's perspective. Use compatible 3.3 V logic and a common ground. Motor power goes directly to external ESCs; do not connect motor windings or battery power to the signal pads. Full pad ordering and wiring notes.

Firmware: what is planned

This repository currently contains hardware and firmware integration documentation, not flight firmware. There is no flashable binary, tested CubeMX project, ready-made Betaflight/INAV/ArduPilot target or qualified DShot DMA map.

The firmware guide covers:

• Clock, peripheral and interrupt assignments for this exact board.
• BMI270 SPI initialization and the BMM350 auxiliary-bus transport.
• BMP390L compensation, EEPROM persistence, UARTs, USB and ADC sensing.
• Proposed acquisition, calibration, estimation, control and mixer modules.
• Arming states, receiver freshness, watchdog/fault handling and telemetry.
• A staged bring-up plan and measurable acceptance milestones.

The intended flow is timestamped sensor acquisition → calibration/filtering → state estimation → control → mixer/limits → ESC commands, supervised by arming and fault logic. Actual scheduling rates, filter settings, PID gains and motor protocol must be selected and validated on the assembled system.

Upstream starting points are STM32CubeF4, BMI270 SensorAPI, BMP3 SensorAPI and BMM350 SensorAPI. They are referenced rather than included as tested dependencies.

Open, fabricate and assemble

1. Clone this repository and open QuadCopter.kicad_pro in KiCad 10.99 or a compatible newer version. Close/reload any editor still holding an earlier board before saving.
2. Read the fabrication instructions, especially fine-pitch solder-mask and J1 locator-hole clearances.
3. Use QuadCopter_RevB_Fabrication.zip for Gerbers and Excellon drills.
4. Use bom.csv, positions-assembly.csv, and assembly-top.svg for assembly. Confirm placement rotation conventions with the assembler.
5. Follow the first-board acceptance procedure using a current-limited supply, then SWD and diagnostic firmware. Keep propellers removed throughout initial motor testing.

Complete project archive · Archive checksums

Generic passives are specified by value/package/tolerance/dielectric/voltage in the BOM. Use the exact C20 reverse-geometry nonmagnetic part. Confirm the retained ROHM 1.8 V regulator's availability before assembly. Do not infer a high-current peripheral rating or flight certification from the existence of manufacturing files.

Reproduce the CAD checks and exports

Python 3 and the KiCad CLI are required; the CAD verification/export scripts use only Python's standard library.

python3 tools/verify_project.py
python3 tools/build_release.py

Set KICAD_CLI if the executable is not on PATH or at the normal macOS location. Verification refills and saves copper zones, checks schematic parity and ERC, then asserts critical net connections/values. The release builder exports manufacturing data and packages the project. Social image generation is separate; see the image-set instructions.

Repository map

QuadCopter.kicad_pro / .kicad_pcb / .kicad_dru
QuadCopter.kicad_sch             Root schematic
mcu.kicad_sch                    MCU, clock, reset, debug
IMU.kicad_sch                    Sensor subsystem
power.kicad_sch                  Input selection and rails
pad.kicad_sch                    External pads
libraries/                      Local symbols, footprints, custom models
docs/                           Hardware/connection guides and images
firmware/README.md               Firmware integration plan (no binary)
manufacturing/                  Gerbers, drills, BOM, placement, SVGs
verification/baseline/           Original CAD-check evidence
verification/final/              Rev B reports, views and source hashes
release/                        Fabrication and complete-project archives
social/linkedin/                Caption, four shareable images, alt text
tools/                          Verification, export and media-generation scripts
HARDWARE_RELEASE.md              Detailed corrections and bench acceptance

Engineering work captured in Rev B

The revision corrects the 3.3 V supply/LED path, USB-C CC resistor values and connectivity, the ADC divider, magnetometer supply/bypass/CRST connections, boot pull-down and crystal selection. It also completes routing, revises ground returns, refines fine-pitch mask geometry, packages local libraries and reorganizes silkscreen. Before/after details and primary sources.

Project images and LinkedIn caption

Download the LinkedIn image kit · Caption · Four-image preview · Upload order and alt text

The images use actual KiCad renders and distinguish CAD verification from pending hardware/firmware tests. Repository access depends on the current GitHub visibility setting.

Next milestones

• Fabricate and inspect the first assembled board.
• Characterize rails, oscillator, USB and peripheral interfaces.
• Implement and test the board-specific firmware/driver layer.
• Calibrate sensors and verify body axes/motor mapping.
• Validate receiver loss, watchdog, reset and brownout behavior.
• Record controlled motor and eventual flight-test results.

Hardware CAD is the current milestone. Every future test result should identify the exact PCB revision and firmware commit used.