Payloady naukowe UAV — od wielkości mierzonej do zbioru danych

Payload naukowy jest instrumentem pomiarowym zintegrowanym z ruchomą platformą, a nie sensorem przykręconym do ramy. Wynik powstaje z całego łańcucha: definicji wielkości mierzonej, poboru próbki lub optyki, kalibracji, czasu, trajektorii, układów współrzędnych, elektroniki, oprogramowania, środowiska UAV i przetwarzania. Bez opisania tego łańcucha plik zawierający liczby może być niemożliwy do interpretacji albo porównania.

Projekt należy rozpocząć od pytania naukowego i wymaganej niepewności, a dopiero później wybierać czujnik. Kamera o dużej liczbie pikseli nie rozwiąże problemu niewłaściwego pasma, rozmycia i braku kalibracji. Czujnik gazu o rozdzielczości wyświetlacza 0,01 nie gwarantuje takiej accuracy, zwłaszcza w strudze śmigieł i przy cross-sensitivity. Sukcesem misji jest zbiór danych zdolny odpowiedzieć na pytanie wraz z granicami stosowalności.

Spis treści#

Od pytania naukowego do wymagania
Measurand i model pomiaru
Klasy payloadów
Requirements traceability
Interface Control Document
Interfejs mechaniczny
Masa, środek ciężkości i bezwładność
Drgania i stabilność linii widzenia
Interfejs elektryczny
Inrush, brownout i sekwencjonowanie
EMI i EMC
Bilans cieplny
Interfejs danych
Budżet przepustowości i pamięci
Czas i synchronizacja
Układy współrzędnych
Lever arm i boresight
Kalibracja
Traceability i uncertainty
Blank, zero, span i reference
Sampling in situ
Downwash i zaburzenie próbki
Payloady obrazujące
Skanery i sensory aktywne
Health, status i autonomia
Integracja z autopilotem
Program testów
Poziomy danych
Formaty i metadane
QA/QC i provenance
Data management plan
Gotowość misji
Typowe błędy

Od pytania naukowego do wymagania#

Pytanie „jaka jest temperatura obszaru?” jest niewystarczające. Trzeba określić:

temperaturę czego: powierzchni, powietrza, liścia, wody;
zakres przestrzenny i rozdzielczość;
czas obserwacji i temporal resolution;
wymagane absolute/relative accuracy;
skalę zmian, którą trzeba wykryć;
confidence i dopuszczalny brak danych;
warunki środowiskowe;
poziom produktu: surowy sygnał, mapa, profil czy estymata.

Przykład wymagania:

The system shall estimate surface radiometric temperature
over 2 km² with 0.5 m output grid, expanded uncertainty ≤ 1.5 K
for surfaces with emissivity 0.95±0.02, atmosphere within the
validated range, and at least 95% valid coverage.

Takie wymaganie ujawnia zależności: radiometria, emisyjność, atmosfera, GSD/MTF, georeferencja, coverage i uncertainty. „Kamera termiczna 640×512” nie definiuje żadnego z nich.

NASA Airborne Science traktuje misję naukową end-to-end: experiment design, requirements, payload integration, flight safety, deployment i operacje, czego przykładem jest program SIERRA UAS.[1] Ta sama dyscyplina jest użyteczna w małym projekcie uczelnianym.

Measurand i model pomiaru#

Measurand to wielkość, którą zamierza się mierzyć. Instrument indication nie musi nią być. Model:

y = f(x_raw, calibration, environment, platform_state, geometry, corrections)

Przykłady:

DN kamery → radiancja → reflektancja powierzchni;
transit time LiDAR → odległość → punkt w układzie mapowym;
napięcie elektrochemicznej celi → concentration po korekcji temperatury, wilgotności i cross-gas;
pressure sensor → ciśnienie po korekcji offsetu, temperatury i dynamiki portu;
particle counter → liczba/rozkład po uwzględnieniu flow rate i sampling efficiency.

Każdy input ma uncertainty i zakres ważności. Jeśli correction variable nie jest rejestrowana, później może nie być możliwe odtworzenie wyniku.

Measurement equation jest częścią konfiguracji produktu danych. Zmiana współczynników lub algorytmu tworzy nową wersję, nie „poprawia po cichu” starego pliku.

Klasy payloadów#

Podział funkcjonalny:

passive imaging — RGB, multispectral, hyperspectral, LWIR;
active remote sensing — LiDAR, radar, sonar;
in situ sampling — gaz, aerozol, cząstki, temperatura, wilgotność, ciśnienie;
collection — próbka powietrza, wody lub materiału;
radiation — dozymetria i spektrometria;
geophysical — magnetometr, gravimeter, field sensors;
meteorological — turbulence, wind, thermodynamic state;
biological/ecological — obraz, akustyka, eDNA sampling;
technology demonstrator — nowy instrument badany przed docelową platformą.

In situ payload mierzy lokalnie, ale może zaburzać medium. Imager nie dotyka celu, lecz zależy od geometrii i atmosfery. Sensor aktywny emituje energię i wymaga bezpieczeństwa, synchronizacji oraz zgodności radiowej/optycznej. Nie ma jednego procesu kalibracji dla wszystkich, ale interfejsy systemowe są wspólne.

Requirements traceability#

Każde science requirement powinno prowadzić do instrumentu, lotu, przetwarzania i testu:

Science need	Derived requirement	Design feature	Verification
wykrycie gradientu 2 K	NETD/system noise i kalibracja	sensor, optics, FFC	blackbody test
mapa 0,5 m	MTF/GSD i georeferencja	lens, altitude, GNSS/INS	resolution target + checkpoints
profil co 10 m	sample interval i speed	trigger/timebase	timing/flight test
porównanie sezonów	radiometric stability	reference target, calibration	inter-campaign check

Traceability matrix zapobiega sytuacji, w której payload spełnia datasheet, ale misja nie spełnia science need. Weryfikacja odpowiada „zbudowaliśmy zgodnie z wymaganiem”, walidacja — „produkt odpowiada na zamierzone pytanie”.

NASA Systems Engineering Handbook wiąże zarządzanie interfejsami z verification/validation oraz utrzymywaniem dokumentów IRD/ICD pod configuration control.[2]

Interface Control Document#

ICD powinien opisać co najmniej:

mechanical envelope / mounting / loads / mass properties
electrical voltage / current / inrush / grounding / protection
thermal dissipation / allowable temperature / airflow
data physical/link/application protocols
time sources / timestamp semantics / latency
coordinate frames / lever arms / boresight
commands / states / interlocks / faults
environment / EMC / ingress
operations / maintenance / safety / ownership

Interfejs to granica odpowiedzialności. Jeśli platforma dostarcza 28 V, ICD musi podać tolerancję, transients, connector, pinout, return, current limit i sequencing. Jeśli payload dostaje pozycję UDP, trzeba podać schema, units, frame, rate, time epoch i behavior po utracie pakietów.

Dokument nie może być tylko rysunkiem mechaniki. NASA stosuje standaryzowane panele EIP zapewniające zasilanie, Ethernet, sterowanie i monitoring, co pokazuje wartość kontrolowanego, powtarzalnego interfejsu.[3]

Interfejs mechaniczny#

Definiuje:

bounding box i sweep envelope gimbala;
punkty mocowania, tolerancje i materiał;
axes oraz mounting datum;
load cases i współczynniki bezpieczeństwa;
środek masy i tensor bezwładności;
stiffness i modal requirements;
access do kart, filtrów i portów;
retention wtórne;
ingress, venting i drainage;
grounding/bonding surface;
instalację bez błędnej orientacji.

Load path powinien omijać delikatną obudowę sensora. Śruby wymagają preloadu, zabezpieczenia i witness marks. Szybkozłącze ma pozytywną indikację lock oraz analizę single-point failure.

Payload wystający w dół zmniejsza clearance. Trzeba uwzględnić compression podwozia, nierówny teren, tilt przy starcie i transport. Osłona optyczna może być potrzebna podczas startu w pyle, ale jej stan musi być monitorowany.

Masa, środek ciężkości i bezwładność#

Masa payloadu zmienia:

thrust/power i endurance;
CoG i trim;
moments of inertia oraz control response;
modal frequencies;
landing loads;
zdolność autorotacji/szybowania zależnie od platformy.

Mierzy się gotową konfigurację z przewodami, komputerem, nośnikami i osłonami. Deklaracja sensora bez harnessu nie jest budżetem.

Moment bezwładności punktowej masy rośnie z kwadratem odległości:

I = m r²

Dlatego 2 kg daleko od CoG może bardziej zmienić dynamikę niż cięższy element blisko środka. Gimbal ma zmienną konfigurację masową. Autopilot i model symulacyjny powinny uwzględniać zakres.

Drgania i stabilność linii widzenia#

Źródła to blade passage, motor electrical order, unbalance, frame modes, aerodynamic buffet i gimbal motion. Sensor widzi kombinację:

source → structural path → mount → instrument response

Miękki mount nie zawsze pomaga. Może wprowadzić rezonans, duże displacement i utratę boresight. Isolation projektuje się z transmissibility i zmierzonym PSD.

Dla obrazu kluczowa jest line-of-sight jitter. Przy focal length f i angular jitter θ przesunięcie na sensorze:

Δx ≈ f · θ

Motion blur zależy od jitter spectrum i exposure. Dla LiDAR/radar drganie zmienia pointing każdego pomiaru. Dla in situ może wpływać na pompę lub złącze, nawet jeśli wynik nie jest obrazem.

Testy obejmują accelerometry na platformie i instrumencie, FFT/order tracking, modal tap test oraz obraz resolution target w locie. Analiza tylko logu IMU autopilota może nie reprezentować payloadu.

Interfejs elektryczny#

Power budget zawiera:

nominal, peak i inrush current;
start-up time;
voltage range i ripple;
load steps;
heater/pump/laser duty cycle;
sleep/standby;
brownout behavior;
regenerative/transient events;
efficiency przetwornic i harness loss.

Źródło platformy może mieć noise od ESC. Payload powinien mieć własne protection: fuse/current limit, reverse polarity, TVS jeśli odpowiednie, filtering, undervoltage lockout i controlled shutdown. Separacja high-current motor paths od analog front-end jest krytyczna.

Grounding architecture rozróżnia chassis, protective/shield i signal returns. Ekran podłączony przypadkowo na obu końcach może tworzyć loop; pozostawiony bez właściwego zakończenia nie działa. Decyzja wynika z EMC design, nie sloganu.

Inrush, brownout i sekwencjonowanie#

Komputer, kondensatory i heater mogą przy starcie pobrać wielokrotność prądu nominalnego. Skutkiem bywa reset autopilota lub payloadu. Testuje się przy najniższym napięciu baterii i najwyższej impedancji harnessu.

Sekwencja:

platform power valid
→ payload rail enable
→ self-test
→ time/navigation valid
→ sensor warm-up
→ calibration/reference
→ science ready

Status powered nie oznacza science ready. Instrument może potrzebować stabilizacji temperatury. Mission planner powinien czekać na jawny stan.

Przy brownout payload zapisuje event, zamyka plik bez korupcji i bez wysyłania przypadkowych komend. Watchdog nie może powodować niekończącej się pętli dużego inrushu.

EMI i EMC#

Payload może zarówno emitować, jak i odbierać zakłócenia. Susceptible systems: GNSS, magnetometr, RC, telemetry, analog ADC i time pulse. Emitters: DC/DC, CPU, Ethernet, laser drivers, radar, heaters PWM i motors/pumps.

Program:

bench near-field/current probe scan;
conducted noise na zasilaniu;
radiated emissions pre-compliance;
susceptibility test w dopuszczonych warunkach;
GNSS C/N0 i compass comparison payload off/on/modes;
radio packet loss/throughput;
sensor zero/noise floor w stanach platformy;
cable configuration worst case.

Nie wystarczy certyfikat modułu, ponieważ integration, harness i enclosure zmieniają wynik. Sensor aktywny musi również spełniać wymagania widmowe i bezpieczeństwa emisji.

Bilans cieplny#

W zawisie może brakować przepływu, który był w specyfikacji sensora. Obudowa na słońcu dostaje solar load, a wewnętrzny komputer wydziela ciepło. Bilans:

C_th dT/dt = P_internal + P_solar
              - Q_convection - Q_radiation - Q_conduction

Projekt uwzględnia:

max/min ambient i altitude;
hover vs cruise;
sun angle i absorptivity;
ground hot soak przed startem;
warm-up i heaters;
component junction temperature;
calibration drift z temperaturą;
condensation/dew point;
thermal coupling do platformy.

Sensor może działać, ale poza skalibrowanym zakresem. Rejestruje się temperatures w science data, nie tylko ostrzeżenie. Thermal chamber test łączy skrajne tryby mocy z profilem lotu.

Interfejs danych#

Warstwy:

physical: Ethernet, USB, CAN, UART, SPI;
link/network: framing, IP, VLAN;
transport: UDP/TCP;
application: messages, files, commands;
semantic: units, frame, timestamp, quality.

Wysoka przepustowość obrazu zwykle używa Ethernet/USB/storage lokalnego; deterministic trigger/status może iść osobnym GPIO/PPS/CAN. Jedna magistrala nie musi realizować wszystkiego.

Schema wiadomości powinna mieć version, sequence, timestamp, source ID, units i validity. Odbiorca musi wiedzieć, co oznacza missing sample, NaN, saturation i warm-up.

NASA NASDAT dostarcza instrumentom Ethernet, state data, NTP, status packets, storage/telemetry i trajektorię do korelacji po locie.[4] Mały UAV może odtworzyć tę architekturę w miniaturze: common time/state bus oraz lokalny recorder.

Budżet przepustowości i pamięci#

Raw rate obrazu:

R = width · height · bits_per_pixel · fps · bands

Przykład 2048×1536×12 bit×20 fps×5 bands to około 3.77 Gbit/s przed packing/overhead — więcej niż typowy link telemetryczny. Potrzebne są lokalny zapis, selekcja i/lub kompresja.

Storage:

S = average_data_rate · mission_time · margin

Uwzględnia filesystem overhead, calibration frames, housekeeping, retransmissions i partial file. Sustained write speed, nie marketingowy peak, jest kryterium. Media testuje się w temperaturze i przy wibracji.

Telemetry powinna wysyłać health, quicklook i wybrane produkty, a nie próbować kopiować całego raw. Priorytetyzacja zapobiega wyparciu command/status przez obraz.

Czas i synchronizacja#

Każda próbka wymaga czasu odpowiadającego fizycznemu zdarzeniu. Możliwe znaczenia:

start exposure;
mid-exposure;
end readout;
ADC sample;
packet receipt;
file write.

Timestamp aplikacji po odebraniu pakietu zawiera zmienne latency. Dla georeferencji ważny jest hardware timestamp lub trigger time. Kamera rolling shutter ma inny czas dla kolejnych wierszy.

Źródła czasu:

GNSS PPS + time message;
PTP/IEEE 1588 w sieci;
NTP dla mniej krytycznych potrzeb;
trigger line i event counter;
monotonic local clock z estymacją offset/drift.

Model:

t_reference = a · t_payload + b + δ_event

Estymuje się offset b, drift a i event latency δ. Po utracie GNSS system przechodzi w holdover i zwiększa time uncertainty. Time jumps są zabronione w surowym timeline; korekcja jest warstwą przetwarzania.

Aktualne CF Conventions 1.13 jawnie rozróżniają kalendarze i traktowanie leap seconds, co ma znaczenie przy danych UTC o dokładności sekundowej.[5] Dataset musi deklarować time scale/epoch, nie tylko tekst UTC.

Układy współrzędnych#

Frame tree:

Earth/map
└── navigation/body
    ├── IMU
    ├── GNSS antenna
    ├── gimbal
    │   └── camera/laser
    └── inlet/probe

Każda transformacja ma translation, rotation, convention, uncertainty i validity interval. ENU/NED, right/left-handed, degrees/radians i quaternion order muszą być jawne.

Sensor in situ ma pozycję inletu, nie anteny GNSS. W szybko zmieniającym się polu lever arm i time offset tworzą przestrzenny błąd. Dla skanera każdy beam ma własny kierunek oraz czas.

Transformacje są częścią kalibracji konfiguracji mechanicznej. Demontaż payloadu może zmienić boresight; repeatable mount powinien mieć zmierzoną powtarzalność.

Lever arm i boresight#

Lever arm r_b między origin platformy a sensorem po rotacji:

p_sensor = p_body + R_world_body · r_b

Velocity offset przy obrocie:

v_sensor = v_body + ω × r_b

Boresight to rotation między sensor frame a navigation frame. Mały błąd kąta rośnie z zasięgiem:

position_error ≈ range · angle_error

1 mrad przy 500 m daje około 0,5 m błędu przed innymi składnikami. Dlatego mierzy się survey lever arms i kalibruje boresight na scenie/trajectory zapewniającej obserwowalność.

Nie należy dopasowywać boresight do tych samych punktów, na których następnie deklaruje się accuracy. Potrzebne są niezależne checkpoints.

Kalibracja#

Kalibracja ustala relację indication–reference pod określonymi warunkami. Może obejmować:

gain, offset, linearity;
spectral response;
geometric intrinsics/distortion;
boresight/lever arm;
time delay;
temperature dependence;
flow rate;
cross-sensitivity;
dark current/noise;
range/angle corrections.

Kalendarz kalibracji nie powinien być wyłącznie czasowy. Triggerami są shock, naprawa, demontaż, drift check, przekroczenie temperatury i wynik quality control.

Pre/post campaign check daje dowód stabilności. Jeżeli instrument zmienił się po misji, nie wiadomo kiedy nastąpił drift; pre/post bracket pomaga ograniczyć ten problem.

Traceability i uncertainty#

Metrological traceability jest cechą wyniku, nie naklejką na przyrządzie. NIST definiuje ją jako udokumentowany, nieprzerwany łańcuch kalibracji do odniesienia, w którym każdy krok wnosi uncertainty; samo posiadanie skalibrowanego instrumentu nie wystarcza.[6]

Budżet niepewności:

u_c²(y) = Σ (∂f/∂x_i)² u²(x_i)
          + 2ΣΣ (∂f/∂x_i)(∂f/∂x_j) cov(x_i,x_j)

Składniki:

reference standard;
calibration fit/residual;
repeatability;
drift;
temperature/environment;
time/geolocation;
sampling perturbation;
correction model;
spatial/temporal representativeness;
processing/resampling.

Accuracy z datasheetu nie jest pełnym uncertainty wyniku w locie. Raport podaje model, coverage factor i warunki.

Blank, zero, span i reference#

Instrumenty potrzebują kontroli jakości w misji:

blank — sygnał przy braku analitu/celu;
zero — punkt zerowy skali;
span — znany poziom w zakresie;
reference — stabilny cel/standard;
dark frame — odpowiedź bez światła;
flat field — spatial response;
check standard — niezależna kontrola kalibracji.

Sekwencja może być przed startem, w locie i po locie. Valve manifold dla gazu musi zapobiegać cross-contamination i logować rzeczywisty stan. Kamera wymaga panelu/reference pod właściwym oświetleniem.

Automatyczna kalibracja nie może nadpisywać raw. Zapisuje coefficients, reference ID i wynik acceptance. Failed check oznacza flagę lub abort zgodnie z science requirement.

Sampling in situ#

Próbka ma miejsce, czas i volume/flow. Projekt inletu obejmuje:

pozycję względem rotora/prop wash i exhaust;
aspiration efficiency;
tubing length, diameter i material;
residence time;
adsorption/desorption;
condensation;
particle losses na zagięciach;
pump flow i calibration;
contamination z platformy;
response time instrumentu.

Transport delay w rurce:

t_delay ≈ V_tube / Q_flow

ale dispersion i sorption wydłużają odpowiedź. Timestamp próbki należy cofnąć o zwalidowany delay, z uncertainty. Dla cząstek inlet orientation względem relative wind wpływa na sampling efficiency.

Materiały i smary UAV mogą emitować VOC lub cząstki. Blank z napędem off/on pomaga zidentyfikować self-contamination.

Downwash i zaburzenie próbki#

Multirotor przyspiesza powietrze i miesza warstwy. Sensor temperatury/wilgoci umieszczony w downwash niekoniecznie mierzy undisturbed atmosphere. Fixed-wing ma prop wash, boundary layer i thermal wake.

Walidacja:

CFD jako hipoteza, nie dowód;
smoke/flow visualization;
multi-position probe test;
comparison z mast/reference;
rotors off/on i różne thrust;
forward speed sweep;
yaw/wind direction sweep.

Wynikiem jest sampling envelope: konfiguracje i prędkości, w których bias mieści się w wymaganiu. Jeśli nie można usunąć wpływu, model korekcyjny i uncertainty muszą być jawne.

Payloady obrazujące#

Oprócz kalibracji radiometrycznej i geometrycznej wymagają:

FOV/GSD/MTF;
focus stability;
exposure/gain;
rolling/global shutter;
line-of-sight pointing;
overlap i terrain following;
band registration;
stray light i flare;
atmospheric correction;
surface BRDF/emissivity;
georeferencing.

Obraz preview może być przetworzony, ale produkt naukowy powinien zachować raw/linear data. Auto white balance, gamma i denoising mogą uniemożliwić ilościową analizę.

Calibration target musi być większy od effective spatial response i dobrze scharakteryzowany. USGS podkreśla konieczność kalibracji UAS imagery do fizycznych właściwości oraz pełnej dokumentacji ELM/paneli.[7]

Skanery i sensory aktywne#

LiDAR/radar/sonar wymagają:

emission timing i waveform;
clock/phase stability;
range calibration;
scan angle encoder calibration;
boresight;
detection threshold;
saturation/multipath;
eye/RF safety i regulatory compliance;
interference z innymi systemami;
per-return quality fields.

Point cloud bez per-point timestamp ogranicza motion compensation. Range accuracy na statycznym celu nie jest map accuracy po połączeniu z GNSS/INS.

Tryb pracy sensora może wpływać na C2 lub GNSS. Interlock powinien blokować emisję w stanie ground/maintenance, jeśli wymaga tego safety case.

Health, status i autonomia#

Payload state machine:

OFF → BOOT → SELF_TEST → WARMUP → CALIBRATE
→ READY → ACQUIRE → DEGRADED → SAFE/ERROR → SHUTDOWN

Health telemetry:

rail voltages/current;
temperatures;
storage remaining/write errors;
time sync quality;
calibration validity;
sensor saturation;
pump/laser/gimbal state;
dropped frames/packets;
last command/result;
data quality flag.

Autonomia może adaptować sampling do zjawiska, ale zachowuje audit trail: trigger, wersję algorytmu i obszary niezmierzone. Adaptive route nie może naruszać constraints lotniczych ani energii.

Science event może generować high-rate burst i quicklook marker, pozostawiając raw do analizy. Algorytm pokładowy nie powinien być jedyną kopią danych.

Integracja z autopilotem#

Payload może otrzymywać:

GNSS/INS state;
attitude/rates;
mission waypoint/progress;
trigger distance/time;
vehicle mode/landed state;
terrain distance;
time sync.

Może wysyłać:

readiness/health;
event/region of interest;
gimbal request;
payload power request;
data rate/storage alert.

Interfejs musi ograniczać authority. Błąd payloadu nie powinien bezpośrednio sterować aktuatorami lotu. Request przechodzi przez zatwierdzoną logikę autopilota/mission managera. Watchdog i rate limit chronią magistralę.

DJI Payload SDK jest przykładem producenta udostępniającego kontrolowane interfejsy zasilania, danych, czasu i funkcji payloadu; zależność od konkretnego modelu i wersji trzeba sprawdzać w macierzy zgodności.[8]

Program testów#

Stopnie:

component/bench — sensor, ADC, pump, optics;
payload standalone — power, thermal, software, calibration;
platform integration — fit, EMC, bus, timing;
ground powered — motors off/on, modes, interference;
restrained/captive lub bezpieczny low-risk — dynamic effects;
envelope expansion — speed, attitude, temperature;
science validation — reference site/instrument;
campaign readiness — end-to-end rehearsal.

Każdy test ma requirement ID, configuration, procedure, expected result, raw evidence i disposition. Pass bez danych nie jest wystarczające.

Fault injection obejmuje loss time, storage full, sensor frozen, packet dropout, overtemperature i calibration failure. Autopilot powinien zachować bezpieczeństwo, a payload jawnie flagować luki.

Poziomy danych#

Praktyczna hierarchia:

raw/L0 — instrument packets/DN/waveforms bez nieodwracalnych korekt;
L1 — calibrated units, time ordered, geolocated podstawowo;
L2 — derived geophysical variable/map/profile;
L3 — gridded/composited multi-flight product;
quicklook — produkt operacyjny, niekoniecznie jakości finalnej.

Definicje poziomów trzeba zapisać lokalnie, bo organizacje używają różnych konwencji. L1 nie powinien usuwać raw. Każdy poziom wskazuje parent files, software version, calibration i quality flags.

Reprocessing po nowej kalibracji tworzy nową wersję L1/L2 z tym samym raw. DOI/identifier i changelog pozwalają cytować właściwy produkt.

Formaty i metadane#

Dla trajectory/time-series/profiles użyteczne są netCDF/HDF5 z konwencjami CF; dla raster GeoTIFF/COG; point cloud LAS/LAZ/E57; obrazy raw + sidecar/EXIF; tabele Parquet/CSV z data dictionary.

Każda variable:

name i standard_name, jeśli istnieje;
long_name;
units;
dimensions/coordinates;
valid range/fill value;
uncertainty/quality flag;
calibration reference;
sampling/averaging method.

Global metadata:

title, campaign, platform, instrument;
creator/institution/contact;
time/space coverage;
CRS/vertical datum/time scale;
processing history;
software commit/container;
license/access;
related raw/calibration datasets.

CF Conventions definiują semantykę zmiennych oraz współrzędnych przestrzennych i czasowych, dzięki czemu użytkownik może ocenić porównywalność danych.[5]

QA/QC i provenance#

Quality flags powinny być bitowe lub enumerowane, nie tylko jedno valid:

0 good
1 warmup
2 calibration_invalid
3 saturated
4 time_uncertain
5 position_uncertain
6 flow_out_of_range
7 platform_contamination_possible
8 interpolation

Provenance graph:

raw packet/file
→ decoder version
→ calibration set
→ navigation solution
→ correction algorithm
→ L1
→ retrieval/model
→ L2 product

Każdy node ma checksum, version, parameters i time. Manual edits są zapisane jako operacje z osobą i powodem.

QA terenowe sprawdza readiness, references i coverage. QC po locie sprawdza drift, gaps, residuals, outliers, cross-sensor consistency i spatial artifacts. Automatyczny raport nie zastępuje science review.

Data management plan#

DMP przed misją odpowiada:

ile danych powstaje na lot/dzień/kampanię;
gdzie jest primary i backup;
kto kopiuje i weryfikuje checksums;
jak nazywa się pliki i identyfikatory;
które dane są wrażliwe;
co jest publiczne i kiedy;
jakie formaty, metadata i licencje;
jak zachować calibration/code/environment;
retention i koszty;
jak cytować dataset.

Zasada 3-2-1 może być punktem wyjścia, ale teren wymaga offline workflow. Karta nie jest archiwum. Po locie wykonuje się verified ingest i dopiero potem reuse media.

Nie należy przechowywać wyłącznie ortomozaiki lub wykresu. Raw i pełne metadata umożliwiają reprocessing po wykryciu błędu.

Gotowość misji#

Checklist review:

Science#

measurand i uncertainty są zdefiniowane;
calibration/validation site i reference gotowe;
sampling design i coverage zatwierdzone;
success/abort criteria znane.

Integration#

ICD i konfiguracja zamrożone;
masa/CoG/loads zweryfikowane;
power/thermal/EMC/timing testy przeszły;
software/firmware hashes zapisane;
spares i narzędzia gotowe.

Data#

czas, units, frames i schema zweryfikowane;
storage margin i ingest przetestowane;
quicklook odróżniony od final;
metadata template i DMP gotowe.

Operations#

lot legalny i bezpieczny;
pogoda/environment w validation envelope;
role, komunikacja i emergency plan przećwiczone;
pre/post references w harmonogramie.

Typowe błędy#

„Sensor ma accuracy ±1%, więc wynik też.” Integracja, sampling, czas, geometria, środowisko i model korekcyjny dodają uncertainty.

„Timestamp pliku jest czasem pomiaru.” Może oznaczać zapis po zmiennym buforowaniu; potrzebna jest semantyka event time.

„Pozycja UAV to pozycja próbki.” Lever arm, inlet delay, attitude i ruch wymagają korekty.

„Miękki mount usuwa drgania.” Może wprowadzić rezonans i duże przemieszczenie; potrzebne są PSD i transmissibility.

„Ethernet rozwiązuje interfejs danych.” Nie definiuje schema, units, time, validity ani zachowania po utracie.

„Kalibracja przyrządu daje traceability danych.” Traceability dotyczy wyniku i pełnego udokumentowanego łańcucha z uncertainty.

„Dron mierzy czyste powietrze obok siebie.” Downwash, prop wash, ciepło i emisje platformy mogą zmienić próbkę.

„Ładna mapa jest produktem naukowym.” Potrzebne są raw, kalibracja, QA, uncertainty, metadata i provenance.

Powiązane tematy#

Przypisy#

NASA Airborne Science Program, SIERRA UAS, end-to-end support od experiment design po flight operations.
NASA, Systems Engineering Handbook, Rev. 2, requirements, interface management, ICD oraz V&V.
NASA EPIC Lab, Experimenter Interface Panel, standaryzowany interfejs zasilania, danych i sterowania instrumentów, aktualizacja 2026.
NASA Airborne Sensor Facility, NASDAT specifications, time, trajectory, state data, networking, storage i telemetry.
NetCDF Climate and Forecast Metadata Conventions 1.13, współrzędne, units, czas i metadata, wydanie 2025.
NIST, Metrological Traceability: Frequently Asked Questions and Policy, łańcuch kalibracji, uncertainty i własność wyniku.
U.S. Geological Survey, Guidelines for Calibration of UAS Imagery, radiometric/geometric calibration i dokumentacja.
DJI Developer, Payload SDK documentation, przykład kontrolowanych interfejsów payloadu i macierzy zgodności.

Źródła z centralnego rejestru

NASA Systems Engineering Handbook, Rev. 2 [oficjalny podręcznik inżynierii systemów i kontroli interfejsów]
NASA Airborne Sensor Facility: NASDAT specifications [dokumentacja standardowego systemu czasu, danych, trajektorii i telemetrii aparatury]
NASA EPIC Lab: Experimenter Interface Panel specifications [dokumentacja standaryzowanego interfejsu zasilania i danych instrumentów]
NASA Airborne Science Program: Airborne Science Instrumentation [dokumentacja programu i integracji aparatury naukowej]
NASA Airborne Science: SIERRA UAS [opis systemu UAS i end-to-end support misji naukowych]
NIST: Metrological Traceability — FAQ and policy [oficjalne wyjaśnienie traceability, kalibracji i niepewności]
NetCDF Climate and Forecast Metadata Conventions 1.13 [aktualna specyfikacja metadanych danych geofizycznych, 2025]
DJI Developer: Payload SDK documentation and supported-product matrix [dokumentacja producenta]
USGS OFR 2023-1033: Guidelines for Calibration of Uncrewed Aircraft Systems Imagery [wytyczne radiometrycznej i geometrycznej kalibracji UAS]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]
Eric Cheng, „Drony. Tajniki zdjęć i filmów lotniczych” [książka]