Robotics and automation engineering for companies without a robotics team.
Automating a task means a mechanism, motor drive electronics, sensing and the software that ties them together, and each of those usually belongs to a different specialist. We would take on all of them under one lead, and the closest thing we have built is a three-board electronics stack for an indoor quadcopter, at v0 design stage.
The problem
A robot or an automated machine fails at the joins between disciplines. A motor driver that does not suit the supply, a sensor that does not fit where the mechanism needs it, or software written without knowing the electronics all cost time late in a project. Companies that have a process to automate but no robotics engineers tend to meet those joins one at a time. We work in C++ and Python, and robotics is our founder’s own field of study: a BEng Robotics at Loughborough, then an MSc Aerial Robotics at Bristol. We would typically start from the task itself, such as what moves, what must be sensed and how often, and work outwards to the hardware and software that suit it.
The decisions we would settle with you early are the ones that are expensive to change later: the supply voltage and the motor type, the sensing approach, how the controller talks to the rest of the machine, and what the machine does when something stops. We would normally settle the sensing and the control approach before fixing the motor and power electronics, since they shape them. Software would be developed against the hardware it will run on, with the interfaces between the two kept simple enough to test one side at a time. Throughout, we would keep a short list of assumptions about loads, speeds and the environment, and test them early, because wrong assumptions cause more rework than wrong parts.
What we'd build
What we would build for an automation project
These are the pieces we would typically cover, with the drone electronics stack as our nearest worked example. That stack is a set of v0 designs in KiCad. None of its boards has been fabricated or flown, so we offer it as design experience and not as proven hardware.
| Layer | What we'd do | Detail |
|---|---|---|
| Motor drive | Power electronics sized to your motors and supply, from gate drivers and MOSFETs to the regulators for the logic. | Our 4-in-1 ESC design pairs gate drivers with 24 N-channel MOSFETs |
| Control | A microcontroller board with its pin and peripheral map worked out before layout starts. | Our flight controller design is built on an STM32F405 |
| Sensing | Position, motion or distance sensing chosen for the job, with a fallback identified where a part is hard to source. | Our downward sensor board pairs optical flow with time-of-flight ranging |
| Interfaces | The connectors, buses and protocols between controller, drivers and sensors, agreed before layout so each part can be tested alone. | |
| Software | Control and application code in C++ or Python, written alongside the hardware so the two fit. | C++ · Python |
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 prototyping ·Drones and aerial robotics ·Embedded firmware development ·Product development · All sectors →