I’m sharing a small open-source project I’ve been working on: a hardware compatibility linter for small mobile robots.
The goal is to catch common electrical and integration mistakes before parts are ordered or soldered.
In practice, many hardware failures are boring but costly:
- Battery voltage outside motor driver limits
- Battery discharge (C-rate) too low for motor stall current
- Driver peak current exceeded across multiple channels
- 3.3V MCUs driving 5V-only logic
- I2C address conflicts
The tool is a deterministic CLI that runs rule-based checks over a simple YAML hardware spec (battery, drivers, motors, MCU, buses). No AI, no simulation-just explicit constraints you can inspect.
Below is a short demo showing a realistic 4-wheel mobile base spec with multiple issues, then fixing the spec and re-running the checks.
Current scope:
- Voltage range compatibility
- Driver continuous & peak current vs motor stall
- Battery C-rate vs worst-case load
- Logic-level mismatches
- I2C address conflicts
This is intentionally early and narrow in scope. I’m posting here to get feedback from people who’ve shipped real robots.
Questions I’d really value input on:
- What hardware failure modes do you hit most often?
- What checks would you expect at the pre-build / BOM stage?
- Where could a tool like this give false confidence?