A camera, a screen and a Renesas RA8P1 evaluation board. The board finds the person in view, marks the key points of their body, and draws the skeleton live as they move. No PC, no cloud, no network: the camera picture stays on the device, which brings body tracking within reach of products where cost and privacy both matter.
Point the camera at a person and the screen shows the live picture with a skeleton drawn on top. It locks on within about a second and follows the head, arms, body and legs as the person moves — and the camera picture never leaves the device.
With application logic on top, a few points per person can be enough to tell standing from sitting, count an exercise, check a posture or spot a fall — without sending any images anywhere. That could bring body-aware features to products built on a microcontroller rather than a PC-class processor.
Count repetitions, check exercise form and track how far a joint moves — in a smart mirror, a home device or a clinic station.
Notice a fall, someone lying still for too long, or an unsafe lifting posture — with the camera picture kept on the device rather than sent to a server.
Check a golf swing, a running stride or a stretch, and give feedback on the device itself — no phone app or cloud service needed.
Let a kiosk, a toy, a display or a robot respond to how a person stands and moves — a raised arm, a wave, someone stepping closer.
These are possible directions for this work, not shipped products. Each would need its own application logic and testing.
Cameras raise privacy concerns, especially in homes, care settings and workplaces. Running the AI on the device itself changes what a product needs to do with the picture.
The camera picture is analysed on the board itself. The demo needs no network connection, no PC and no cloud service to track a person.
The AI's output is a set of body points, not an image. A product could act on those points alone — a repetition counted, a fall flagged — without storing or sending any video.
A device that does not need a network for its AI has no path for camera pictures to leave it. That is a simpler privacy story to tell users than promises about how cloud data is handled.
Each camera picture is prepared for the AI model, the model finds the person in it, and the skeleton is drawn back over the live picture. We built the AI step two ways: on the chip's built-in AI accelerator (NPU), and on its main processor alone.
Both versions run on the real board and show the same skeleton on screen. Together they show clearly what the NPU adds in speed, and give a working starting point for either kind of design.
The AI model runs entirely on the NPU, so the skeleton keeps up with every camera picture, with most of each frame's time left over for the rest of the product.
With the NPU switched off, the main processor runs the same model and updates the skeleton about 6 times a second — enough to follow a person who is not moving fast.
Because everything except the AI step is shared, the two versions can be compared directly. Times were measured on the board; the time left over is worked out from those measured times.
| With the NPU | CPU only | |
|---|---|---|
| Time for the AI step | 12 ms | 155 ms |
| Skeleton updates per second | 19 — every camera frame | about 6 |
| Time left in each camera frame | about 70% | — |
The NPU earns its place. It makes the AI step 12.9× faster and keeps up with every camera frame, with about 70% of each frame's time left over for the rest of the product.
And for designs that must run without an NPU, the CPU-only version gives a measured reference speed — a useful starting point when choosing a chip.
Getting an AI model to run is only the start. Making its answers correct on real hardware took deeper work — the kind of issues that give wrong results rather than an obvious crash.
The NPU and the main processor were not always seeing the same data, so the processor could read out-of-date results. We found the cause and fixed it, so the skeleton is drawn from the NPU's latest result.
The two versions are kept as separate projects, so a change to one does not affect the other, and every change we made to vendor code is clearly marked with what it replaced and why.
We streamlined how each camera picture is prepared for the AI model, so the whole step takes just 2 ms and leaves more time for the rest of the application.
The model tracks best when it can see the whole body, from head to feet. We checked on the board how framing affects tracking, which gives a clear starting point for placing the camera in a product.
This is an R&D build, not a product, and it already runs on hardware. The spare time it leaves opens several directions.
Pose estimation often runs on a PC-class processor or in the cloud. On the RA8P1 it runs live, beside a camera and a display, with images kept on the device. Measuring the same model with and without the NPU makes this more useful than a demo: measured numbers to inform the choice of chip, and a tested starting point for product development.
That is the discipline we bring to every engagement: hardware-aware intelligence. We bring up the model, fix what only shows up on real hardware, and measure the options on the board — so the hardware decision is made on evidence, not on a datasheet.
This is one build from our Renesas RA8P1 R&D work. Share your idea and your hardware targets, and we'll show you what it takes to run pose estimation on your device — with or without an NPU.
services@gnomons.com