OptiMaP: swarm-powered Optimized 3D Mapping Pipeline for emergency response operations
Notice bibliographique
Résumé
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.293km <sup xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">2</sup> . 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.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,000 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,000 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,003 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».