hello@dothex.net

+44 (0) 20 3290 3080

London, UK

FREE CONSULTATION

Embedded Systems & Product Development Consultancy · London, UK

Edge AI and embedded machine learning

Why a model that works on a laptop fails on a device

Most edge AI projects don’t fail on accuracy. They fail on memory, speed, power and the data the real sensor produces.

  • The model doesn’t fit: too many weights for the flash, activations too large for the RAM.
  • It fits, but it’s too slow for the frame rate or drains the battery in hours.
  • Accuracy drops after 8-bit quantisation, and nobody measured it on the target.
  • The camera or sensor on the device sees different data from the training set.
  • The model is an island, with no clean way to feed it data, act on its output or update it in the field.

Edge AI is an embedded systems problem as much as a data science one. We work on both halves.

What we build with edge AI

  1. Vision on microcontrollers. Object detection and image classification on NPU-equipped microcontrollers with low-power camera sensors.
  2. Sensor and time-series models. Anomaly detection, activity and gesture recognition, and condition monitoring from vibration, current or IMU data.
  3. Audio and acoustic events. Keyword spotting and sound event detection that run continuously within a small power budget.
  4. Vision on embedded Linux. Larger models on Linux processors with NPUs or GPUs, with the camera pipeline and application around them. →
  5. Model optimisation. Quantisation, pruning, operator checks for the target NPU, and memory planning so weights and activations fit.
  6. Firmware integration and updates. Sensor capture, pre-processing, inference scheduling and model updates over the air, separate from the firmware. →

From data to a deployed model

  1. Feasibility first. Target accuracy, latency, power and cost decide the hardware class: microcontroller, microcontroller with an NPU, or a Linux processor.
  2. Data that matches the device. Collected with the real sensor or camera, in the conditions the product will see, then labelled and split.
  3. Train and compress. A baseline model, then quantisation and pruning to fit, checked against the operators the NPU actually supports.
  4. Measure on the target. Accuracy, latency, memory and energy per inference measured on real hardware, not estimated from a desktop run.
  5. Integrate and ship. Pre-processing, scheduling and actions in the firmware, with versioned models that can be updated in the field.

Platforms and toolchains

NPU microcontrollers: STM32N6 with the Neural-ART accelerator, Arm Cortex-M55 with Ethos-U55, NXP MCX N and i.MX RT700 with the eIQ Neutron NPU, ESP32-S3

Linux and accelerators: NXP i.MX 8M Plus and i.MX 93, NVIDIA Jetson, Raspberry Pi with AI accelerators

Frameworks: TensorFlow Lite for Microcontrollers (LiteRT), ST Edge AI, NXP eIQ, Edge Impulse, ONNX, PyTorch, Arm CMSIS-NN

Tools: Python, NumPy, OpenCV, on-target profiling with power analysers

Algorithms on constrained hardware

Client names stay private. The engineering doesn’t.

Detection algorithms and safety-critical firmware for a device built at over a million units

View case studies

A low-power wearable medical device, from concept to pre-production

Read the case study

Recent edge AI work

Ask about this work

Frequently asked Edge AI device questions

Can our model run on a microcontroller?

Often, yes. Small vision, audio and sensor models run well on modern NPU microcontrollers once quantised to 8-bit; larger models need a Linux processor with an NPU or GPU. We check with your model, or a comparable one, before you commit to hardware.

Microcontroller, NPU or embedded Linux?

It depends on model size, frame rate, power budget, cost and what else the device has to do. A microcontroller with an NPU often gives the best power for vision; Linux makes sense when the model or the camera pipeline outgrows it.

Do you train models or only deploy them?

Both. We can train and optimise models with your data, or take a model from your data science team and make it run on the device.

How much data do we need?

Less than most teams fear, as long as it comes from the real device in real conditions. We plan data collection with the first prototypes so the dataset grows with the product.

Can models be updated after launch?

Yes. The model is versioned and stored separately from the firmware, and updated over the air with the same signing and rollback as a firmware update.

Does on-device AI help with privacy?

Yes. Images and audio stay on the device and only results leave it, which simplifies data protection and cuts bandwidth.

Have a model that needs to run on a device

Talk to an engineer

Latest from the blog