Input A, hardware
Hardware: Robotics and embedded systems design
Machines that survive the real world.
WhiteHat Design Studio designs and builds robots and embedded systems in Pakistan, the boards, the firmware and the mechanics, for the day they leave the lab. Prototypes are easy. Deployments are the job.
Boards, firmware and machines
What it will look like.
One job from start to finish, on the kind of screens we build. Press a step to stop on it.
Who it is for
Founders and CTOs at robotics and device companies
The worry The prototype never becomes a product.
What we do You have a demo. We make it survive the real world, starting with the riskiest part.
Software companies meeting hardware
The worry Firmware is unknown territory.
What we do We write the firmware and the interface your app talks to, so your team works with messages, not registers.
Manufacturers and operators
The worry Vendors who blame each other.
What we do The sensor, the board and the software that reads them come from one team, so there is nobody else to point at.
What we build.
Robotics and autonomous platforms, embedded systems on STM32 and ESP32, motor control, sensors and communications, IoT devices, mechanical design and industrial automation.
Robots and autonomous platforms
Mobile bases, navigation and the onboard computers that run them. HARP and Auto Vendi both find their own way through a building.
Embedded systems
Firmware on STM32 and ESP32 for control, sensing and communications, and Raspberry Pi 5 where a system needs Linux and onboard AI.
Motor control
Drives for wheels, heads and fingers. ReFlex stops each finger on encoder feedback, so the grip ends where it should.
Sensors and communications
Cameras, depth sensors, muscle-signal (EMG) sensing and line sensors, and the links between devices.
IoT devices
Small connected devices and what they talk to. SceneScribe's cane carries an ESP32 that joins the headset's own Wi-Fi access point.
Mechanical design
Frames, enclosures, mechanisms and printed parts. The ReFlex fingers are 3D-printed in TPU 95A and pulled closed by strings, like tendons.
Switch it off.
An input on its own is not a product, and a product without hardware is not finished either. Try it.
Switch hardware off and see what happens to the product. The other inputs link to their own pages.
Output Y = 1
It works, and customers are using it.
Evidence.
Published work that used this practice, with what each one does.

Case study, aerial surveillance
SKYLOCK
Finds drones in live camera feeds, predicts where each one is going and keeps a gimbal camera on it, from the operator's console or on its own.
A hardware, B software, C AI
Case study, assistive robotics
HARP
Navigates a mapped building, tracks faces and holds a conversation with an onboard language model, built around a Raspberry Pi 5.
A hardware, C AI
Case study, last-mile logistics
Auto Vendi
Maps its route, avoids obstacles and delivers in a locked compartment that the phone app releases.
A hardware, B software, C AI
Research prototype, assistive robotics
ReFlex
Reads forearm muscle signals, chooses a pinch or tripod grip from what the palm camera sees, and stops each finger on encoder feedback.
A hardware, C AI
Prototype, assistive technology
SceneScribe
Describes what the camera sees, in answer to the wearer's own question, through earphones.
A hardware, B software, C AI
Competition robot
Tree-planting robot
Follows the arena's lines, plans on a grid and places blocks with its own mechanism.
A hardwareHow it connects.
An input on its own is not a product. These are the places hardware meets the rest.
Hardware and software
Auto Vendi's compartment lock is released from a phone app. The lock, the robot and the app are one prototype, so the button and the lock agree.
Hardware and AI
HARP runs its language model on the robot itself, so the conversation happens on board, and the computing, the power and the model all have to fit together.
Hardware and growth
A device that works and nobody knows about has still failed. When the hardware is ready, growth is how buyers hear about it, in claims the engineers who built it would sign.
What we do not do
- We do not run volume manufacturing. We hand over files your manufacturer can build from, and we can work with them.
- We do not certify products. We design for the standard you need and work with your test house.
Guides from this work
- How does drone detection work?
Drone detection finds a drone with one or more sensors: radar, a radio receiver, microphones or a camera. Each one has a blind spot, so the strongest systems combine them. A camera system such as SKYLOCK runs a detection model on every frame, predicts where the drone is going and turns a gimbal to keep it in view.
- STM32 vs ESP32: which should your product use?
Use an ESP32 when the product's main job is to connect, because Wi-Fi and Bluetooth come on the chip. Use an STM32 when its main job is to control something on an exact schedule, such as a motor. When a product needs both, use one of each and join them with a serial link.
- Edge AI or cloud AI: where should your model run?
Run the model on the device when the machine has to keep working without a network, answer quickly or keep its data to itself. Run it in the cloud when the model is too large for the device and the answer can wait for the network. Many systems do both: fast decisions on the device, heavy work on a server.
- Visual SLAM vs LiDAR SLAM for indoor robots
SLAM lets a robot build a map and work out where it is on that map at the same time. Visual SLAM does it with cameras, which cost less and see detail but need light and texture. LiDAR SLAM does it with a laser scanner, which measures distance directly but costs more and can miss glass.
- How to turn a prototype into a product
Define what working means, in numbers with their conditions. Build the riskiest part first and test it where it will be used. Then design for manufacture and prove the product in three builds: engineering, design and production. A prototype proves an idea once. A product has to work every time, for people who never met the engineer.
Questions buyers ask.
Are you a robotics company?
Yes. We design and build robots and the systems around them. HARP is an assistive humanoid robot, Auto Vendi is a delivery robot, and SKYLOCK keeps a camera gimbal on a moving drone.
Do you do STM32 and ESP32 firmware development?
Yes. SKYLOCK uses STM32 control hardware, and the SceneScribe cane carries an ESP32 that joins the headset's own Wi-Fi access point. Our guide on choosing between the two explains when each one fits.
Which microcontrollers and boards do you work with?
STM32 and ESP32 for embedded control and communications, and Raspberry Pi 5 where a system needs Linux and onboard AI. HARP is built around a Raspberry Pi 5, and ReFlex runs its grip model on one.
Can you take our prototype and make it reliable?
You have a demo. We make it survive the real world. We define what working means, prototype the riskiest part first, and test it where it will live.
Do you design circuit boards?
Yes. The boards, the firmware and the mechanics are all input A, and the design files and bills of materials are yours at handover.
Do you do mechanical design as well as electronics?
Yes. Mechanical design is part of input A. The ReFlex fingers were designed in Fusion 360 and SolidWorks and printed in TPU 95A, and the tree-planting robot carried its own payload mechanism.
Do we get the schematics, board files and firmware source?
Source code, firmware, design files, bills of materials and credentials, handed over at the end.
Do you manufacture in volume?
We do not run volume manufacturing. We hand over files your manufacturer can build from, and we can work with them.
Tell us what has to work.
One sentence is enough. An engineer will reply.