Project plan

A SpeedyBee F405 V3–style flight controller, built for disposable, high-speed research drones.

Last updated: 2026-09-22

1. What we're actually building

Let's be precise about the spec, because "clone the SpeedyBee F405 V3" and "build for research drones that get smashed into obstacles" pull in slightly different directions, and the plan needs to reconcile them:

• Core: STM32F405 MCU, USB-C for firmware flashing/configuration, Betaflight-compatible (so we inherit a mature, tested firmware stack instead of writing our own flight software).
• Power: Needs to handle high current — these will fly fast, probably on punchy motors/higher cell counts, so current sensing and copper/trace sizing need real margin, not hobby-grade margin.
• Use case: Research drones with simple flight profiles (no acro, no complex maneuvers) but high speed and sharp responsiveness — basically "point it at a target fast and reliably," not "freestyle."
• Lifecycle: Single-use / disposable. The drone (and probably the FC with it) gets destroyed on impact as part of the test. This changes the economics of the whole project — see §3.
• ESC: Open question — separate 4-in-1 ESC board (stack) vs. integrated ESC-on-FC (AIO). See §4, this is the first real decision to make.
• Funding: Hack Club Forge (a Hack Club "YSWS" — You Ship, We Ship — program that funds teen hardware projects, forge.hackclub.com) plus other sources.

2. The single most important design principle for this project

Design for volume and disposability, not for repairability.

A normal FPV flight controller is designed assuming the pilot cares about salvaging it after a crash — that's why the FPV industry mostly builds stacks (separate FC + ESC) instead of AIO boards: if the ESC dies, you replace a $15 ESC instead of a $60 combo board. But that logic doesn't apply to you. If the whole drone gets smashed into a wall on purpose, the FC dies with it regardless of whether it's a stack or AIO. Optimizing for post-crash repairability is optimizing for a scenario that won't happen.

What you should optimize for instead: - Cost per unit, since you'll be building many of these and throwing them away. - Build/assembly time per unit — fewer boards, fewer connectors, fewer solder joints = faster to produce in batches. - Reliability during the test itself — it has to survive vibration, current spikes, and hard maneuvers right up until the moment it's supposed to be destroyed. Nothing worse than a research drone that fails for an unrelated electrical reason and ruins a test run. - Consistency — every unit should behave identically so your crash-test data isn't contaminated by board-to-board variance.

This principle should be your tie-breaker any time you're stuck between two design options below.

3. Decision: integrated ESC (AIO) vs. separate ESC stack

Given §2, I'd lean AIO (ESC integrated onto the FC board) for this project, with one caveat. Here's the actual trade-off:

The caveat: thermal headroom is the real risk with AIO under "high current" and "high speed." Mitigate it with layout, not by abandoning AIO: - Use a 4-6 layer board with dedicated copper pours for the ESC power stage (2oz copper minimum on the power layers). - Keep MOSFETs away from the STM32 and IMU so ESC heat doesn't cook the flight sensors or destabilize the gyro readings. - Since flights are short (point-and-crash, not endurance racing), you're dealing with current spikes, not sustained thermal soak — which favors AIO more than a typical 10-minute freestyle flight would.

If you find during prototyping that thermal margin is a real problem (e.g., you're going to 6S+ or very high KV motors), fall back to a stack — the FC side of this plan doesn't change either way, you'd just delete the ESC section from the schematic and add a 4-pin ESC signal header instead. I'd suggest prototyping the AIO version first since it validates both boards' worth of design in one board, and only splitting it out if testing shows you need to.

4. Reference architecture (based on the real SpeedyBee F405 V3)

The actual SpeedyBee F405 V3 has a published Betaflight "unified target" resource map (it has to, for Betaflight to support it out of the box) — this is the closest thing to a real schematic reference we have without a teardown, and it's the right starting point to copy-and-tweak. Key facts pulled from the unified target config (SPBE-SPEEDYBEEF405V3.config, see RESOURCES.md):

• MCU: STM32F405, 8 MHz HSE crystal, Betaflight 4.3+ compatible.
• Gyro/IMU: BMI270 (I2C in the V3; later revisions like V4 use ICM42688P over SPI — SPI is faster and lower-latency, worth considering as your "minor tweak" since responsiveness is one of your stated goals).
• Current sensor: ADC pin with a defined scale factor (386 in the stock config) — i.e. an analog shunt-based current sense circuit feeding straight into the STM32's ADC, not a separate digital current-sense IC. Simple and cheap, which fits your cost target.
• 8 motor outputs across two timers with DMA, UART1–UART6, SPI1–SPI3, SD card slot for blackbox, MAX7456 OSD chip, beeper, LED strip pin, camera control pin.
• USB: PA11/PA12 (D-/D+) straight into the STM32's USB OTG FS peripheral — this is what lets it enumerate as a DFU device with zero extra silicon (see §5).

Suggested "minor tweaks" for your version, given your actual requirements: 1. Switch to SPI-based IMU (ICM42688P or similar) instead of I2C BMI270 — lower latency, higher ODR, better for "responsive" flight. This also future-proofs against BMI270 supply issues. 2. Drop the OSD chip, SD card slot, and blackbox logging if your test rig already captures telemetry another way (see §8) — every chip you remove is cost and assembly time saved across a whole batch. Only keep what you'll actually use. 3. Size the current-sense shunt and copper pour for your real max current, not generic hobby FC defaults — work backward from motor KV × cell count × prop size to get a worst-case current number before finalizing the shunt value and trace widths (see §6). 4. Consider a lower pin/component count UART set — you probably need one for RC receiver (ELRS/CRSF) and maybe one for a companion telemetry/logging link. You likely don't need all 6 UARTs SpeedyBee exposes; cutting unused UART headers saves board space and connector cost.

5. USB-C programming interface

This is simpler than it sounds — you're not implementing USB-PD or high-speed data, just DFU firmware flashing and Betaflight Configurator communication over USB Full Speed, which the STM32F405's built-in USB OTG FS peripheral handles natively.

Minimum viable USB-C circuit: - USB-C receptacle, D+/D- routed to PA11/PA12 (as in the reference design above). - CC1 and CC2 pins each need a 5.1kΩ pull-down resistor to GND — without this, USB-C chargers/hosts won't apply power or a host won't recognize the device as a non-PD USB 2.0 peripheral. This is the single most common USB-C mistake on hobby boards — don't skip it. - ESD protection diode array on D+/D-/VBUS (cheap, e.g. USBLC6-2SC6, standard on every FC that has USB-C). - BOOT0 pin wired to a bootloader-entry mechanism — Betaflight boards typically do this automatically in firmware (the flash trigger reboots into DFU mode via software), but keep a manual BOOT0-to-3V3 solder pad/bridge as a hardware fallback in case firmware ever gets bricked. This has saved more than one board.

6. High current handling

Given "handle high currents" and "go to high speeds" are explicit requirements, don't treat this as an afterthought:

1. Work out real numbers first. Pick your motor (KV), cell count, and prop size, then get the realistic peak current draw (motor manufacturer data + a safety margin, not datasheet best-case). This number drives the shunt resistor value, MOSFET selection (if AIO), copper weight, and trace widths — do this before finalizing the schematic, not after.
2. Current sensing: the stock analog shunt-into-ADC approach (like the reference design) is fine and cheap. If you want more accuracy/noise immunity at high current, a dedicated current-sense amplifier (e.g., TI's INA240, bidirectional, rated up to 80V and built for exactly this kind of high-current low-side or in-line sensing — see TIDA-00913 reference design in RESOURCES.md) is a small cost add that pays off in cleaner telemetry.
3. Copper and trace sizing: use an online trace-width calculator (IPC-2152) for your worst-case current, and round up. For the battery-to-ESC power path specifically, prefer wide copper pours over traces where possible, and consider 2oz (or heavier) copper on at least the power layers.
4. MOSFET selection (if going AIO): pick MOSFETs rated for at least double your expected continuous current — datasheet ratings assume test conditions your cramped drone PCB won't match. Pair with a gate driver that has undervoltage protection thresholds compatible with your logic voltage (common pitfall called out in several ESC hardware-design writeups — see RESOURCES.md).
5. Input capacitance: budget roughly 250–500µF per motor at the power input (mix of ceramics and a bulk electrolytic/polymer cap) to absorb switching noise and current spikes — exact value needs bench validation, it's not a pure calculation.
6. DShot + AM32 or BlueJay firmware (open source, well-supported, no per-unit licensing cost unlike BLHeli32) if you go integrated ESC — this also means you can reflash/debug ESC firmware yourself instead of depending on a closed-source binary.

7. Firmware strategy

Don't write flight-control firmware from scratch — build a custom Betaflight target. This is the single biggest time-saver in this whole project:

1. Fork Betaflight, add a new target folder (e.g. KARA or similar 4-letter target code) mapping your actual pins — the SpeedyBee V3 unified target file is your starting template, edit the pins to match your schematic.
2. Get it accepted into (or just locally build against) betaflight/unified-targets so Configurator can find it, or just compile and flash your custom .hex/.bin directly via DFU — you don't strictly need to upstream it if this is just for your own batch of boards.
3. If going AIO with integrated ESC, flash AM32 (open source, STM32/GD32/AT32 support, active development, full DShot bidirectional + RPM filtering) onto the ESC-side MCU if you use a separate small MCU per motor, or wire DShot output pins directly if your design integrates ESC logic differently.
4. Test firmware bring-up in stages: power rails → USB enumeration → IMU communication → motor DShot output → RC link — in that order, on the bench, before ever spinning a prop.

8. Rough milestone plan

This is a real plan with checkpoints, not a wish list — treat each milestone as a go/no-go gate before spending money on the next batch of boards.

Phase 1 — Schematic & design validation (target: 1-2 weeks) - Finalize component selection (MCU, IMU, current sensor approach, USB-C, ESC approach from §3). - Draw full schematic in KiCad, cross-check every net against the reference pin mapping. - Get a design review (Betaflight Discord / r/fpvbuilds / your local hackerspace — free, catches dumb mistakes before they're etched in copper).

Phase 2 — PCB layout (target: 1 week) - Route the board — 30.5×30.5mm mounting pattern if you want frame compatibility with existing SpeedyBee-pattern hardware, or your own footprint if not. - Follow high-current layout rules from §6 for the power path specifically. - Design rule check (DRC) + manufacturability check against your fab's capabilities (JLCPCB is the default cheap option — check their min trace/space and copper weight options match your design).

Phase 3 — First prototype batch (target: 2-3 weeks incl. fab lead time) - Order a small batch (5-10 boards) — enough to have spares for bring-up mistakes, not a full production run. - Decide hand-assembly vs. JLCPCB PCBA (turnkey assembly) for this batch — hand-soldering an STM32F405 (LQFP, 0.5mm pitch) is doable but fiddly; turnkey assembly removes a lot of risk for not much more money at low volume. - Bring up one board fully before touching the rest: power-on test, USB enumeration, DFU flash, IMU read, motor DShot signal on a scope/logic analyzer.

Phase 4 — Firmware + bench validation (target: 1-2 weeks, overlaps Phase 3) - Build and flash your custom Betaflight target. - Validate gyro/IMU orientation and noise, current sensor calibration, DShot to motors, RC link. - Run current-draw tests on a bench power supply/dyno if you have access to one, to confirm your shunt/trace sizing was right before you're committed to a full batch.

Phase 5 — Integration into the actual test drone (target: ongoing) - Mount in the airframe, verify vibration isolation (soft-mount the FC — even disposable drones benefit from clean gyro data for the flights leading up to impact). - End-to-end flight test on a non-destructive first flight if at all possible, to confirm the board actually flies as expected before you start sacrificing units.

Phase 6 — Production run for the actual research campaign - Once the design is validated, order your real batch size based on how many test drones the research plan calls for. - Budget for attrition beyond just "one FC per test" — expect some fraction to be dead on arrival or die in bring-up, not just in the planned crash.

9. Cost & funding notes

• Hack Club Forge (forge.hackclub.com) is a Hack Club YSWS program specifically for funding teen hardware projects — check their current process (it's evolved over time) for exactly how reimbursement/funding works before you order anything, so purchases stay eligible. Their GitHub repo (hackclub/forge) has contributing docs if you want technical detail on how the platform works.
• Since you're also seeking funding elsewhere, keep a clean, itemized BOM with per-unit and per-batch costs early — this is the single most useful document for any funding conversation, and you'll want it anyway for the disposable/volume-cost reasoning in §2.
• Get 2-3 fab quotes (JLCPCB, PCBWay, etc.) at your actual expected batch size — small-batch PCBA pricing has a lot of fixed cost baked in, so cost-per-unit at 10 boards looks very different from cost-per-unit at 100.
• Cheap wins for a disposable design: use JLCPCB's "basic parts" library where possible (lower assembly cost than extended parts), avoid exotic/low-stock components that cause requoting delays, and don't over-spec connectors — solder-direct wiring is fine and cheaper than fancy solder-free connectors if nobody needs to service the board afterward.

10. Open questions to settle before Phase 1 is "done"

• Final call on AIO vs stack once you have real motor/current numbers (§3, §6).
• Exact IMU part (BMI270 vs ICM42688P vs other) — availability and cost matter as much as spec here.
• Whether you need onboard blackbox/SD logging at all, or whether the research rig captures flight data externally — this affects whether you keep the SD card slot and OSD chip.
• RC link protocol (ELRS is the open-source, cheap, low-latency default most current builds use) — confirms your UART count needs.
• Target batch size for the real research campaign — this changes fab/assembly strategy (hand-solder vs. turnkey PCBA) more than anything else in this plan.

This plan is meant to be a living document — update it as decisions get made and as prototyping surfaces real numbers that override the estimates above.