Robotics prototyping, from control board to working prototype.
A robot prototype needs a controller, motor drive, sensing and software that all agree with each other, and a company without robotics engineers has to hold those together alone. Our three-board electronics stack for an indoor quad, at v0 design stage, is an example of how we lay one out.
The problem
Prototypes are often assembled from whatever is on hand, and the integration problems then show up late. We would design the electronics as one set. In our drone stack the three boards share a single mounting pattern, and each outline was sized against its parts list. The flight controller did not fit at 20 × 20 mm, and a double-sided courtyard fill of about 75 per cent measured as too tight, so it is 36 × 36 mm. The ESC parts list did not fit at 27 × 27 mm or 36 × 36 mm, so that board is 40 × 40 mm. The sensor board is 36 × 36 mm and 1.6 mm.
Those decisions are cheap on paper and costly after boards are made. We would expect your prototype to have a similar mix of boards, and we would set the shared pattern first so that a change to one board does not force changes to the others. The sensor board also shows the stage honestly: its LED drive is untested, and the sensor and lens still need consignment. Prototype software would be C++ and Python, written to run against the hardware it is meant for.
Prototyping is about learning quickly without making the learning expensive. We would decide with you which risks the prototype is meant to retire, such as whether a sensor sees what is needed, whether a motor driver copes with the load or whether the controller has enough headroom, and design the first boards to answer those questions. Test access matters more on a prototype than on a product, so we would leave room for probes and debug connectors. Software for a first version would favour clarity over cleverness, with the control loop and the logging easy to read.
What we'd build
What a robotics prototype would include
Our drone boards are all v0 designs. None has been fabricated, powered or flown, so we present them as design experience and not as tested hardware. The rows show how we would work on a prototype for you.
| Layer | What we'd do | Detail |
|---|---|---|
| Control board | A microcontroller board with the pin and DMA map settled before layout. | Our flight controller uses an STM32F405RGT6 and a map taken from an open-source flight-firmware target |
| Actuation | Motor drive electronics sized to the actuators and supply you choose. | Our 4-in-1 ESC targets 2 to 4S packs and the AM32 firmware |
| Sensing | Sensors chosen for the task, with a fallback named where a part is hard to get. | Our downward sensor board uses a PAA3905 and a VL53L1X, with a fallback flow sensor identified |
| Software | Control and test software in C++ or Python alongside the hardware. |
How working with us goes
- 01 Scope We agree what has to be built, where it lives and where the data goes.
- 02 Prototype Working hardware and firmware on your bench, tested against real conditions.
- 03 Pilot A small batch on real sites, with fixes folded back into the design.
- 04 Production Design for manufacture, a production run, and support once it is in the field.
Related
Robotics and automation ·Drones and aerial robotics ·Enclosure design ·PCB design · All sectors →