Automating KiCAD schematics and the FMUv6C redesign

Programmatic schematic generation for PX4 flight controllers and the challenges of redesigning FMUv6C with component shortages

The automation challenge

When you’re reverse-engineering open-source flight controller designs and planning your own variants, one task repeats endlessly: schematic creation. The PX4 hardware ecosystem has decades of design work scattered across GitHub repositories, but translating that into a workable schematic for a custom redesign is tedious — especially when you’re dealing with dozens of connectors, power domains, and signal paths that need consistent naming.

This pushed us toward programmatic schematic generation for KiCAD, where the circuit logic lives in structured data files and the visual schematic is generated as output. The approach lets you focus on the electrical design rather than manually placing hundreds of labels and symbols.

FMUv6C redesign

Our initial plan was to reproduce the Pixhawk FMUv6C — the latest generation in the Pixhawk open-source standard. The STM32H743 MCU (169 pins, LQFP) powers both the main flight unit (FMU) and the input/output board (IO), running the full PX4/ArduPilot stack.

The schematic generation project revealed several design decisions to make:

  • Connectors: CAN1/CAN2, DSM/RC, PPM/SBUS, SBus output, FMU PWM (AUX), IO PWM (MAIN), and debug ports needed consistent pin assignments
  • Power management: Understanding the full power tree, including PSM (Power Selection Module) integration
  • Level shifting: FMUv3 used SN74LVC8T245 for IO PWM channels, but the FMUv6C design consolidated everything through TXS0108
  • Signal clarity: Power labels in light red, ground labels in green, and proper sub-sheet organization for the power domain

The component crisis

Just as the schematic design was taking shape, the market shifted. Flight control component prices surged dramatically — some IMU models disappeared from the market entirely.

“Flight control component prices have risen significantly, with some IMU models showing shortages and惊人的 price increases.”

The BMI055, specified for the Pixhawk 6C, became unavailable. The Bosch FAE themselves recommended the BMI088 as a pin-compatible replacement for drone applications, and it was in stock through multiple channels.

The root cause appeared to be a large unmanned aircraft order placed by a certain country, triggering a rush for flight control parts across the market. As one supplier put it:

“During this six-month transition period, flight control products will be prioritized for long-term cooperation customers and regular patrons.”

This reinforced our decision not to pursue FMUv6C mass production at this stage. The unit cost, driven by HDI PCB requirements (buried vias, 8-layer stack-up) and component scarcity, made it difficult to price competitively. One HDI PCB quote came in at 550 TWD per board with a minimum order of 200 pieces — meaning even 20 boards would cost 110,000 TWD.

Power tree analysis

The Holybro 6C power tree provided a reference for understanding the complete power domain architecture:

The design separates power into distinct domains: battery input, FMU power, IO power, sensor power, and servo power. Each domain has its own voltage regulation, fault detection, and monitoring circuits. Key signals include N_BRICK_VALID, FMU_BAT2_V, VDD_3V3_SENSORS_EN, and various current/voltage monitoring ADC inputs.

Understanding this architecture was essential before proceeding to any custom hardware design — both for ensuring compatibility with existing power modules and for planning where our own voltage regulation and protection circuits would fit.

What’s next

With the FMUv6C redesign on hold due to cost and supply constraints, we shifted focus toward smaller-scale projects that could move faster. The RP2350B-based flight controller (using BetaFlight) and the TFC1 custom PCB became our primary development paths — projects where the component availability was better and the form factor allowed more flexibility in design decisions.

The schematic generation tool itself remains a valuable asset for any future hardware iteration, and we’re considering open-sourcing it for the community.

Questions? Requests? Suggestions?

We are looking forward to hearing from you!

Are you looking for
Consulting Services,
Support Plans or
Training & Workshops?