IDEEZA
Inventors describe a device in plain words and get a buildable board design
IDEEZA wanted anyone with a hardware idea to say it and get a design. We built the engine in eight modules, with language AI only reading the request and rules and search choosing parts, placing and routing the board, so every design is checked before files exist.
B2B SoftwareGenerative hardware design engineEngineering delivered by Datics
- Input
- A spoken or typed request for a device
- Output
- Circuit board, Gerber files and Android app
- AI's job
- Reads the request; rules check the design
- Engine
- Eight modules, from request to control app
The starting point
IDEEZA is a hardware innovation platform for people with product ideas who are not electrical engineers. Its web and mobile apps needed an engine that turns a request such as a wireless video doorbell or a drone into a working design.
What had to change
The engine had to understand a vague request, pick parts, lay out and route a circuit board, fit it in an enclosure and produce files a manufacturer accepts. No public training data existed for requests about electronic components.
What could not break
- Every design had to be electrically valid, low cost and buildable by a real PCB manufacturer, whatever the user typed.
The calls we made
We split one request into eight modules, each with the technique that fits it, and gave language AI only the job it is good at.
- 01
Language AI reads, it does not design
The language model extracts components, functions and values from the request; component choice, placement and routing are rule and search based, so each output can be checked against hard electrical requirements.
- 02
Generate our own training data
No public data covered requests about electronic components, so we generated domain examples with Chatito, filtered out the noisy ones and tagged every entity and value.
Ruled outGeneral corpora and pretrained word vectors, which extracted electronic components poorly.
- 03
Test the language options, then commit
We compared fastText, LDA and word2vec on the generated data before choosing RASA for entity extraction and, in a second phase, RASA Core for the follow up dialogue.
Ruled outfastText, LDA and word2vec, tested and not chosen.
- 04
The cheapest combination that is stable
Component selection checks voltage, current and input needs in priority order, adds parts where a need is not met and returns the lowest cost stable set.
- 05
Apps assembled from blocks
Each sensor or communication part has its own Kotlin code block, and the blocks snap together into the control app for that device. Kotlin made the small block language easy to write.
Ruled outJava for the app generator.
What we built
Request understanding
A RASA NLU module that pulls components, functions and values such as angles and durations from the request, with a RASA Core dialogue layer for follow up questions.
Board design
Component selection, placement with a Learning Classifier System using reinforcement learning, and automated A* routing across any number of board layers, finishing a full route in minutes depending on board size.
Enclosure fit
Bin packing of multiple boards and batteries inside the cover and modified A* for natural 3D wire routes.
Manufacturing files and control app
Gerber files built from placement, routing and drilling data for PCB manufacturers, stored per run, and an Android app generated for each device, such as a drone or a video doorbell, that controls it.
How it works
The user asks
Someone types or says what they want to build, such as a wireless video doorbell.
The request becomes parts
The language module returns the functions and components it heard, such as Wi-Fi, video capture and a push button.
Rules pick a stable set
Each part's power and input needs are checked and the cheapest stable combination is chosen.
The board is laid out
Parts are placed, every connection is routed and the boards are packed into the cover.
Files and app come out
Gerber files for the manufacturer and an Android control app are generated and saved for that run.
A closer look
What changed
IDEEZA got an engine that takes a plain request through to manufacturing files and a control app, with the AI confined to reading the request. The client kept us on for a long engagement and rated the work five stars.
- 5 stars
- Client rating
“We worked with him for a very long time - and he always surprised us with his work in the project, he was always a step ahead of what we asked for, and shared his knowledge with us in other things as well.”
Under the hood
- Datics role
- Engineering delivered by Datics
- AI boundary
- Language AI only extracts components and values; electrical checks, placement and routing are rule and search based.
- Manufacturing output
- Gerber files built from placement, routing and drilling data, each run kept in its own timestamped folder.
- App generation
- Kotlin code blocks per part, assembled into an Android APK by a Python build script.
Apps and APIs
Also in the stack
How it shipped
Inside the client's product effort
Our team worked as IDEEZA's engineering arm to its roadmap: we owned the backend engine and the Android app module, and the client owned its product and frontend.
One engine, designed as a whole
One lead designed the AI approach across all eight modules, so reading the request, choosing parts, placing and routing were planned as one engine with checks between steps.
Two phases for the language module
Reading the request came first, with RASA NLU on our generated data; the follow up dialogue with RASA Core came in a second phase, before the design modules.
What this unlocked
The same pattern, a narrow job for the model and hard checks on everything it touches, is how we add AI to products where outputs must be right.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.