OptiMaP: swarm-powered Optimized 3D Mapping Pipeline for emergency response operations
Bibliographic record
Abstract
A smart application in sensing is mainly powered by a two-stage process comprising sensing (collect data) and computing (process data). While the sensing stage is typically performed locally through a dedicated Internet of Things infrastructure, the computing stage may require a powerful infrastructure in the cloud. However, when connectivity is poor and low latency becomes a requirement — as in emergency response and disaster relief operations — edge computing and ad hoc cloud paradigms come in support to keep the computing stage locally. Being local network connectivity and data processing limited, it is vital to properly optimize how the computing workload will be consumed by the local ad hoc cloud. For this purpose, we present and evaluate the swarm-powered Optimized 3D Mapping Pipeline (OptiMaP) for emergency response 3D mapping missions, which is implemented as a collaborative embedded Robot Operating System (ROS) application integrating an ad hoc telecommunication middleware.We simulate — with Software-In-The-Loop — realistic 3D mapping missions comprising up to 5 drones and 363 images covering 0.293km2. We show how the completion times of mapping missions carried out in a typical centralized manner can be dramatically reduced by two versions of the OptiMaP framework powered, respectively, by a variable neighborhood search heuristic and a greedy method.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.001 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.000 |
| Insufficient payload (model declined to judge) | 0.003 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".