Radar Based Human Activity Recognition

LOSO Per-Fold Accuracy
Per-Class F1-Score
Per-Class Recall
Fold5 Accuracy And Loss Curves Of CNN
Fold3 Accuracy And Loss Curves Of CNN
Fold4 Accuracy And Loss Curves Of CNN
Fold1 Accuracy And Loss Curves Of CNN
Fold2 Accuracy And Loss Curves Of CNN
Confusion Matrix
Raspberry Pi
Data Collection Hardware SetUp
Terminal Output of activity prediction when connected to Raspberry Pi

Inspiration

Camera-based fall detection and activity monitoring systems face a real problem: people don't want cameras in their bedrooms and bathrooms, even for their own safety. We wanted to build something that could give elder-care and activity-monitoring systems the same capability — recognizing a fall, recognizing distress — without ever capturing an image. Radar can see motion without ever seeing you.

We had already been working with a 77 GHz FMCW radar (TI AWR1843BOOST) on human activity recognition as part of ongoing M.Tech research. When the Arm AI Optimization Challenge came up, it was the perfect forcing function to ask a harder question than "does this model work?" — namely, "can this actually run efficiently on real, cheap, low-power Arm hardware?" That's a very different, much more concrete engineering problem, and we wanted to answer it honestly rather than just claim it.

What it does

Our system classifies 8 human activities — walking, jumping, hand movement, standing up, sitting-to-walking, running, falling, and empty/no-activity — directly from 77 GHz radar micro-Doppler signatures. No camera, no wearable, just radar.

We built this end-to-end: a custom physics-informed CNN trained on real radar captures, rigorously evaluated with cross-session validation, then optimized and deployed on a Raspberry Pi 5 — running entirely on the Pi's Arm Cortex-A76 CPU, no GPU involved, with a live inference demo to prove it.

How we built it

Data capture: We used a TI AWR1843BOOST radar with a DCA1000EVM capture card to record raw ADC data across 5 sessions, processing it into 128×32 micro-Doppler spectrograms for 8 activity classes.

Architecture: Rather than reusing a generic image-classification CNN, we designed a dual-branch architecture matched to the physical structure of radar data. A spectrogram's two axes — velocity and time — represent genuinely different physical quantities, so we gave each its own specialized branch: a 7×1-kernel "Doppler branch" for velocity structure, and a 1×7-kernel "Temporal branch" for how that signature evolves over time. The two branches are concatenated into a classifier head. The whole model is 483,144 parameters.

Evaluation: We used 5-fold Leave-One-Session-Out (LOSO) cross-validation — training on 4 sessions and testing on a completely unseen 5th session, rotating which session is held out. This is a much stricter test than a random split, which can let a model quietly learn session-specific quirks instead of the activity itself. Our model reached 95.34% ± 1.49% cross-session accuracy this way, beating a pretrained EfficientNet-B0 baseline (85.1% ± 3.3%) — evidence that the physics-informed design was actually doing something, not just adding complexity.

Arm optimization: We exported the trained model to ONNX, verified the export was numerically lossless against the original PyTorch model (0.000000 max difference), and then tested both dynamic and static INT8 quantization on the target hardware rather than assuming either would help. Static quantization — calibrated using 100 real radar spectrograms, stratified evenly across all 8 classes — is what we deployed. On a Raspberry Pi 5, it delivered 1.42× lower latency (8.61 ms vs. 12.21 ms fp32), a 72.6% smaller model, and 116.2 inferences/sec, all running CPU-only on the Pi's Arm Cortex-A76.

Challenges we ran into

A hardware parsing bug that looked like a model problem. Early on, an incorrect transmit-antenna configuration in our radar capture pipeline was silently corrupting the byte-frame parsing. It took real debugging to trace what looked like a modeling issue back to a one-line hardware configuration error. Once fixed, our range-Doppler maps were clean, and everything downstream got meaningfully better.

Quantization did the opposite of what we expected. Our working assumption going in was that any INT8 quantization would speed things up. Dynamic quantization actually made inference 68% slower on our Raspberry Pi 5 — because it mostly benefits Linear/fully-connected layers, and our architecture is almost entirely convolutional. That result could have been the end of the story ("quantization didn't help"), but it pushed us to properly implement static quantization with real calibration data instead of guessing — which is where the actual speedup came from. We think this is a more honest and more useful engineering story than "we used INT8 because INT8 is fast."

Being precise about what our accuracy numbers actually claim. It would have been easy to quote our 95.34% LOSO accuracy next to our INT8 deployment results and let a reader assume the quantized model achieved that number under the same rigorous test. It didn't — we only verified INT8 accuracy parity on a calibration slice, not independently under LOSO. We chose to report that distinction explicitly rather than blur it, even though the blurred version would have looked more impressive at a glance.

Accomplishments that we're proud of

A genuinely physics-informed architecture, not a repurposed image classifier, that measurably outperforms a strong pretrained baseline.
A rigorous, cross-session evaluation methodology (LOSO) that we didn't shortcut even though it's more work than a random split.
Two real experimental findings on quantization strategy — one negative (dynamic INT8 regressed latency), one positive (static INT8 delivered a genuine 1.42× speedup) — both measured on real Arm hardware, not assumed.
A complete, reproducible pipeline: every number in our results can be regenerated by running our scripts in order, on a real Raspberry Pi 5.
Keeping our accuracy claims scoped correctly even where a vaguer claim would have sounded stronger.

What we learned

Designing a model around the physical structure of your data (rather than defaulting to whatever architecture pattern is popular) pays off, and can beat much larger pretrained backbones.
"Test, don't assume" applies just as much to optimization techniques as it does to model architectures — our whole quantization strategy changed because we measured instead of assumed.
Rigorous evaluation protocol (LOSO) and honest metric-scoping (calibration-slice vs. independent test) are not academic nitpicks — they're what makes a result someone else can actually trust and build on.
Edge deployment constraints (CPU-only, limited memory) are a real design axis, not an afterthought tacked on at the end.

What's next

Moving from file-based radar capture to live, continuous streaming inference.
Validating the deployment pipeline on additional Arm platforms beyond the Raspberry Pi 5.
On-device power and thermal profiling, since latency alone doesn't capture the full edge-deployment picture.
An independent LOSO evaluation of the quantized model specifically, to close the one gap we were explicit about above.