System architecture
The stack behind
the spec sheet.
Fifty representative open-hardware builds, mapped by domain and stripped down to the layers that matter: sensors, real-time control, Linux autonomy, firmware and licenses. The field index tells you what to build and how to buy it; this is how the machine is put together.
Four tiers, one machine.
Local-first by defaultThe recurring architecture is not a single board. It is a chain: a sensor module hands a digital stream to a real-time microcontroller, a Linux computer turns that stream into a model, and a local interface exposes the result without asking a cloud for permission.
Actuation sits inside the real-time tier: BLDC controllers, steppers, servos, relays and safety contactors all need predictable loop timing. The Linux tier plans; the MCU commits.
Ten builds, side by side.
Representative specs, not a buyer's guideThese are the builds where the architecture is easiest to see: the same Pi-plus-MCU pattern, but very different sensor suites, actuators and real-time deadlines.
Specs are drawn from project documentation and the ecosystem analysis. Revisions, options and vendor bundles vary; check the project's own BOM before ordering.
Six domains,
fifty builds.
Grouped by engineering problem
The stack repeats across domains. What changes is the sensor suite, the actuator budget and the consequence of missing a deadline.
This taxonomy groups 50 representative builds by engineering domain. The field index ranks 76 projects for buying and support; they overlap, but they answer different questions. Linked names open the matching field-index entry.
What changed.
Three shifts behind the boardsBack to discovery
Pick a build.
Then read the stack.
The field index ranks projects by community support, documentation and buying path. The supply map turns the BOM into suppliers. This page is the engineering layer between them.
Need the parts?
Start with the supply map, then paste the BOM into the matcher before opening supplier tabs.