Describe the robot.
Get the parts list that survives contact with a bench.
RoboPilot turns a project brief into an architecture, a priced bill of materials, logic-level checks between every part, a milestone chain and a scored risk register. Prices and compatibility come from a verified catalog and live store pages — the model proposes, it never quotes.
- catalog
- 26 parts
- price sources
- 4 stores
- guessed prices
- 0
Every number here was computed, not written
The model decomposes the brief and names candidate parts. From there the application takes over: prices come from the verified catalog, compatibility from datasheet logic levels, risk from measurable inputs. Ask the model for a price and it has nowhere to put one — the schema it answers in has no price field at all.
Bill of materials
| Part | Qty | Unit | Line |
|---|---|---|---|
| ESP32-WROOM-32 DevKit | 1 | $9.50 | $9.50 |
| HC-SR04 | 1 | $3.50 | $3.50 |
| L298N | 1 | $4.50 | $4.50 |
| MG996R | 2 | $6.50 | $13.00 |
Catalog total $30.50In the live tool, a real store price replaces a unit price when a store responds and the figure survives a plausibility check. Catalog figures are shown here so this example stays reproducible.
What the checks caught
incompatibleGPIO
HC-SR04 operates at 5V logic but ESP32-WROOM-32 DevKit only supports 3.3V — a logic-level shifter is required on GPIO.
incompatiblePWM
L298N operates at 5V logic but ESP32-WROOM-32 DevKit only supports 3.3V — a logic-level shifter is required on PWM.
compatiblePWM
MG996R logic level (3.3/5V) matches ESP32-WROOM-32 DevKit (3.3V) on PWM.
technical riskscore 9/9
2 component pair(s) have a logic-level or interface mismatch.
schedule riskscore 2/9
Milestone dependency chain is 3 step(s) deep across an estimated 9 day(s).
Five steps, and only the first one is the model
A plan is assembled in a fixed order, and each step either produces something traceable or says it could not. The division of labour is the product.
- groq, gemini on failure
Decomposes the brief into blocks
Requirements and constraints go in; architecture blocks come out, each with its inputs and outputs named. This is the one step the language model owns.
- 26 parts, each with a datasheet
Resolves part names against a verified catalog
A proposed name is matched to a catalog entry by name or alias, then by substring, so "DHT22 (AM2302) temperature sensor" still resolves. What does not resolve is labelled not in catalog and priced at nothing — never guessed.
- I2C, SPI, UART, GPIO, PWM, analog
Checks logic levels, pair by pair
Every peripheral is compared against every microcontroller in the plan for a logic-level overlap, and the verdict comes with the voltages it was based on. It never claims a pair was physically tested.
- egypt and international storefronts
Fetches real prices, then distrusts them
Store search pages are fetched at request time and read for a price. A figure outside 0.15× to 6× of the catalog reference is rejected and the catalog price stands — a scraped $0.15 for a $9.50 board is a bug, not a bargain.
- schedule, availability, technical, budget
Scores risk from things it can measure
Dependency depth, unresolved parts, failed pairs and BOM-versus-budget. When nothing is priced it says the budget cannot be assessed, instead of reporting $0.00 as low risk.
Boards it can check a signal against
Compatibility is only as real as the specs behind it. These are the controllers in the catalog today, with the logic levels every check is computed from. Each entry has a datasheet recorded in docs/source-register.md.
- Arduino Nano5 V
- Arduino Uno R35 V
- ESP32-WROOM-32 DevKit3.3 V
- Raspberry Pi Pico W3.3 V
Not in the catalog yetSTM32 Jetson ROS 2 BMP280 coreless motorsPropose one of these and the plan will say it could not verify the part, which is the honest answer until someone adds it with a real datasheet.
Wire it into whatever you already use
The web app is one client of the API, not the product boundary. If your team keeps its BOM in a sheet or a tracker, the plan is JSON on the way there.
{
"projectName": "Obstacle-avoiding rover",
"requirements": ["Detect obstacles within 30cm"],
"constraints": ["Budget under $80"],
"budgetUsd": 80,
"targetPlatform": "esp32",
"priceRegion": "egypt"
}- One endpoint
- POST /api/robopilot. JSON in, a validated plan out. No SDK, no client library, no auth to wire up.
- Validated at both ends
- The request is parsed against a Zod schema before anything is spent, and the assembled plan is parsed again before it is returned. A malformed plan fails loudly rather than reaching your UI.
- Runs without provider keys
- Set ROBOPILOT_STUB_MODE=true and the route returns a canned decomposition with the real deterministic pipeline behind it. The test suite runs this way; so can your CI.
- Fails to a known state
- Both providers down returns 502 with a code and no internals. Live pricing failing anywhere keeps catalog prices. An oversized body is refused at 20,000 bytes.