Before AI can find people under rubble, it needs the right data
Ask what makes an AI model good at finding a person under rubble, and most people will point to how the model is designed. In our work in the Cynergy4MIE project, the harder question has been the data: what the model learns from, and how we know it is good enough to rely on.
By the Strikersoft team
Why this work matters
Cynergy4MIE is a European research project with 39 organisations from 8 countries. Strikersoft's part is research into radar sensing and AI models that can detect people behind debris, in darkness or in smoke, and check whether they are breathing without touching them, and we test this work on our own testbeds.
Because it is an Edge AI implementation, the models are meant to run on small, low-power devices, so we work closely with our partners at KTH, who are designing the chip for such devices and described it in From Drone to Decision. This article is about the step that comes before the chip and the model, which is preparing the data.
Where our data comes from
We did not wait for our own recordings to get started. The research began with publicly available radar datasets of human activity, namely Radar signatures of human activities from the University of Glasgow and DIAT-μRadHAR. The most important data, though, comes from our own sensors. Oleksandr Mruga made our first recordings in January 2025 with a mmWave radar, helped by volunteers from our Romania office, and since then we have added new recording sessions and simulated scenarios.
Only good labels make data useful
Before a model can learn from a recording, someone has to label it, marking where the people are and what else is in the scene. These labels are the ground truth, the correct answers the model learns from and is checked against.
“Supervised learning and the validation stage need ground truth, and that comes from an expert who labels each scene of a recording session by hand.”
That makes labelling one of the most expensive parts of the work.
“Every minute of a data session recorded in the field takes the same time to label, and often much longer. That dramatically increases the cost of creating a dataset.”
There is a second problem as well. More data does not automatically make a model better, and a batch of poorly labelled recordings can quietly make it worse.
What we built
To take this routine work off people's hands, we have built the foundation of a data pipeline. It covers the full cycle of data production, from the moment a recording is made to labelled data stored in a database.
It works like an assembly line where each step is tuned for time and cost, although the process is not rigid: it has its own KPIs, and we keep adjusting it as we watch the quality of the output. Model training is not part of the pipeline yet, and we come back to it at the end of the article.
Current pipeline and planned stages (training, optimisation, deployment).
- Recording and checking. New files are checked automatically, so corrupted recordings never enter the dataset.
- Uploading. The checked recordings go to the cloud, where the rest of the process runs.
- Automatic labelling. A separate AI model works only with the radar data. Judging by the energy of the radar signal, it decides whether a person is in the scene and marks how many people there are. We do not use an RGB camera as one of our sensors, and camera images and detailed labels are only there to describe each scene properly, so that we can see in what conditions our AI makes mistakes.
- Expert review. The expert checks and corrects the labels, and this feedback helps the labelling model improve.
- Database and dashboard. The labelled data is stored in a database and shown visually in Splunk, so the team can follow every change over time.
The pipeline runs in the background while the team works on other parts of the project. Because the labelling model does the first pass, the expert only validates the result, which saves weeks of tiring manual work and leaves people with the more creative and interesting part of the job. We will measure the time saved with a clear metric and share it once it is ready.
What we learned
Data deserves as much attention as the model, because even a well-designed model makes poor decisions when it learns from poorly labelled data. More data is not automatically better data either, which is why we plan to test every batch before it is used for training. Labelling is monotonous work, so we let AI do the routine part, and the team gets more time for the creative work that really needs people.
None of this is specific to search and rescue. Wherever AI learns from sensor data, the same approach should make development faster and data preparation cheaper, and it leaves a clear record of how each dataset has changed over time.
What comes next
The pipeline as it stands is a starting point. There are never enough hands for this kind of work, so we want people's time to go where it counts, and much of the process can still be automated.
The next step in the project is automatic model training, so that the search and rescue model can be retrained and tested on new data as it arrives. That is also our answer to the second problem, because once every new batch is tested before and after training, we will see whether it makes the model better or worse. The last stage of the pipeline will then prepare the model for an edge device, which means estimating the resources it needs and deploying it to test devices.
We also need to test the model in real conditions, which is why edge deployment will be automated too. This step matters because the hardware has strict limits. AI models often need more memory and computing power than a small device can offer, so each model has to be optimised and compressed into a format the device can run.
The same infrastructure will keep reducing costs outside Cynergy4MIE as well, in the NeAIxt project and in projects for our clients. We will keep sharing our progress as the project moves forward, and you can find more about our AI projects on the Strikersoft AI Innovation Center page.
Funded by the European Union and Vinnova in the CHIPS-JU programme.
This work used two publicly available datasets: Radar signatures of human activities by F. Fioranelli, S. A. Shah, H. Li, A. Shrestha, S. Yang and J. Le Kernec (University of Glasgow, 2019), and DIAT-μRadHAR by M. Chakraborty, H. C. Kumawat, S. V. Dhavale and A. B. Raj (IEEE Sensors Journal, 2022).
