Łącze wideo UAV jest szeregiem kolejek i transformacji: sensor naświetla obraz, kamera go odczytuje, procesor przetwarza i koduje klatkę, transport dzieli strumień na pakiety, radio nadaje je w zmiennym kanale, odbiornik porządkuje dane, dekoder odtwarza klatkę, a ekran czeka na następne odświeżenie. Niskie opóźnienie powstaje przez kontrolę każdego z tych etapów. Sam szybki nadajnik ani deklaracja „zero latency” nie usuwają buforów kamery, kodera i wyświetlacza.

Wideo obserwacyjne, pomiarowe i operatorskie mają inne wymagania. Strumień do inspekcji może tolerować kilkaset milisekund opóźnienia w zamian za ostrość i niezawodność. Obraz służący do pilotażu wymaga przede wszystkim przewidywalnego czasu glass-to-glass i łagodnej degradacji. Materiał radiometryczny lub fotogrametryczny może wymagać zachowania metadanych, wysokiej jakości zapisu lokalnego i nie powinien polegać wyłącznie na skompresowanym podglądzie radiowym.

Spis treści#

Wymagania według funkcji#

Specyfikację zaczyna się od obrazu na ekranie, nie od nazwy kodeka:

funkcja priorytet tolerowane zachowanie przy pogorszeniu
pilotaż lokalny FPV niskie i stabilne opóźnienie spadek jakości bez długiego zamrożenia
obserwacja/inspekcja szczegół i czytelność chwilowy spadek FPS lub bitrate
termowizja poszukiwawcza kontrast, georeferencja, ciągłość kontrolowane obniżenie rozdzielczości
pomiar/fotogrametria materiał źródłowy i metadane podgląd może być gorszy; zapis lokalny pełny
monitoring autonomiczny wejście dla algorytmu, timestamp jawna flaga braku/nieaktualności klatki

Wymagania liczbowe powinny obejmować co najmniej:

  • rozdzielczość, klatki/s i zakres tonalny;
  • medianę oraz 95. i 99. percentyl opóźnienia glass-to-glass;
  • maksymalny czas zamrożenia i czas odzyskania;
  • minimalną czytelność przy docelowej dynamice sceny;
  • bitrate średni, szczytowy i zapas kanału;
  • zachowanie przy kolejnych poziomach utraty pakietów;
  • temperaturę pracy i moc obliczeniową;
  • poufność, integralność i sposób ustanawiania kluczy.

Tor od fotonu do ekranu#

Uproszczony pipeline:

ekspozycja → readout sensora → ISP → konwersja formatu → encoder
  → packetizer → kolejka sieciowa → radio → kanał → radio odbiorcze
  → reorder/jitter buffer → depayloader → decoder → compositor → display

Całkowite opóźnienie:

t_g2g = t_exposure + t_readout + t_isp + t_encode + t_queue_tx
      + t_radio + t_network + t_jitter + t_decode + t_display

Niektóre etapy zachodzą potokowo, więc nie zawsze wystarczy zsumować czas pełnej klatki. Mimo to równanie pomaga lokalizować problem. Jeśli kamera buforuje trzy klatki przy 30 FPS, powstaje około 100 ms jeszcze przed radiem.

Kamera i akwizycja#

Ekspozycja#

Długi czas ekspozycji rozjaśnia obraz, ale dodaje rozmycie ruchu i co najmniej część opóźnienia. Przy szybkim locie automatyka ekspozycji nastawiona na statyczne nagranie filmowe może uczynić szczegóły na ziemi nieczytelnymi. Dla pilotażu warto ograniczyć maksymalną ekspozycję i zaakceptować wyższe wzmocnienie/szum.

Rolling shutter#

W rolling shutter wiersze są odczytywane kolejno. Klatka nie opisuje jednej chwili, a obrót platformy powoduje pochylenie i falowanie geometrii. Global shutter eksponuje całą klatkę jednocześnie, lecz może być droższy lub mieć inny kompromis czułości. Stabilizator obrazu nie usuwa informacji, która nigdy nie została zarejestrowana w tej samej chwili.

ISP#

Image Signal Processor wykonuje demosaicing, redukcję szumu, korekcje optyczne, balans bieli, tone mapping i wyostrzanie. Każdy blok może używać bufora klatkowego. W torze operatorskim część „poprawiaczy” warto wyłączyć, jeśli zwiększają opóźnienie lub tworzą artefakty utrudniające ocenę ruchu.

Interfejs#

MIPI CSI-2 pozwala przekazać obraz bez konwersji USB, ale wymaga zgodnego SoC i sterownika. UVC/USB upraszcza wymianę kamery, lecz urządzenie może samo kodować MJPEG/H.264 i ukrywać bufor. V4L2 w Linuksie daje API do negocjacji formatu oraz kolejki buforów; liczba buforów i metoda I/O wpływają na latency.

Rozdzielczość, FPS i surowy bitrate#

Nieskompresowany strumień 1920×1080, 30 FPS, 24 bity/piksel:

1920 × 1080 × 30 × 24 ≈ 1,49 Gbit/s

Format YUV 4:2:0 8-bit ma nominalnie 12 bitów na piksel:

1920 × 1080 × 30 × 12 ≈ 746 Mbit/s

To pokazuje, dlaczego kompresja jest potrzebna. Rozdzielczość nie opisuje jednak jakości. Obraz 1080p przy zbyt małym bitrate może zawierać mniej użytecznych detali niż poprawnie zakodowane 720p. Wysoki FPS poprawia płynność i zmniejsza interwał między klatkami, ale zwiększa ilość danych oraz wymagania kodera.

W analizie trzeba rozdzielić:

  • format sensora/ISP;
  • format wejściowy encodera;
  • bitrate zakodowanego elementary stream;
  • narzut packetization, FEC, szyfrowania i warstwy radiowej;
  • rzeczywisty airtime.

Kodek i kompresja międzyklatkowa#

ITU-T H.264/AVC kompresuje obraz przestrzennie i czasowo. Obraz dzielony jest na bloki; encoder przewiduje ich zawartość z sąsiedztwa lub innych klatek, a następnie koduje różnicę, wektory ruchu i informacje sterujące. H.265/HEVC może uzyskać podobną jakość przy niższym bitrate, ale zwykle wymaga bardziej złożonego kodera/dekodera i może mieć inne opóźnienie sprzętowe oraz warunki licencyjne.

Najważniejsze parametry nie ograniczają się do bitrate:

  • profil i poziom kodeka;
  • rozmiar GOP i częstotliwość obrazu odświeżającego;
  • obecność B-frames oraz kolejność kodowania/dekodowania;
  • liczba obrazów referencyjnych;
  • tryb rate control i rozmiar VBV;
  • liczba slice'ów i sposób packetization;
  • QP minimalne/maksymalne;
  • lookahead i funkcje analizy wieloklatkowej.

Ustawienia przeznaczone do archiwizacji często zwiększają opóźnienie: lookahead wybiera lepsze decyzje dopiero po obejrzeniu przyszłych klatek, B-frames wymagają reorderingu, a duży VBV wygładza bitrate kosztem bufora.

GOP, I/P/B i propagacja błędu#

I-frame może być dekodowana bez poprzedniej klatki tego GOP; P-frame przewiduje z wcześniejszych obrazów; B-frame może korzystać także z obrazu przyszłego w kolejności prezentacji. W praktyce dokładna semantyka zależy od kodeka i konfiguracji.

Długi GOP zwiększa efektywność, ale utrata ważnych danych referencyjnych może psuć wiele kolejnych klatek. Krótki GOP częściej odświeża obraz, lecz I-frame tworzy duży chwilowy bitrate. Kanał, który mieści średnio 4 Mbit/s, może przepełnić kolejkę podczas I-frame o kilkukrotnie większym strumieniu chwilowym.

Typowy problem:

utrata fragmentu IDR → brak poprawnej referencji → artefakty/zamrożenie
                    → oczekiwanie na kolejne IDR

Odbiornik może poprosić o odświeżenie przez feedback RTCP, lecz żądanie, reakcja encodera i wysłanie dużej klatki również zajmują czas. W łączu o wysokiej stracie częste IDR mogą nasilać przeciążenie.

Sterowanie bitrate#

CBR#

Constant Bitrate dąży do stałego strumienia, ale realizacja wykorzystuje bufor i zmienia QP. Przy nagłym wzroście złożoności sceny jakość spada albo chwilowy bitrate nadal przekracza cel. „CBR 4 Mbit/s” nie gwarantuje identycznej liczby bitów w każdym oknie 10 ms.

VBR#

Variable Bitrate przydziela więcej danych trudnym scenom. Daje lepszą efektywność jakościową, lecz wymaga kanału i kolejek zdolnych przyjąć burst. W UAV ruch trawy, wody i tekstury terenu jest trudny do kompresji; statyczny test w laboratorium mocno zaniża wymagany bitrate.

Capped VBR i VBV#

Praktycznym kompromisem jest VBR z limitem oraz niewielkim VBV. Rozmiar bufora powinien wynikać z dopuszczalnego opóźnienia i burst capacity radia. Zbyt mały bufor powoduje gwałtowne skoki QP, zbyt duży ukrywa przeciążenie jako narastający latency.

Kodowanie sprzętowe i kolejki#

Sprzętowy encoder odciąża CPU, ale jest układem z własnymi kolejkami i ograniczeniami. Niektóre sterowniki zatrzymują kilka buforów wejściowych, inne kopiują dane między pamięciami. Zero-copy zmniejsza koszt i jitter, o ile kamera, ISP i encoder dzielą kompatybilne bufory.

Do diagnostyki potrzebne są znaczniki czasu:

t_sensor_start
t_capture_ready
t_encoder_in
t_encoder_out
t_packet_sent

Bez nich wysoki encoder FPS nie dowodzi niskiego opóźnienia. Pipeline może przetwarzać 30 klatek/s, pozostając stale pięć klatek w tyle.

Przy przeciążeniu tor operatorski powinien odrzucić starą klatkę przed kodowaniem lub transmisją, a nie bez końca powiększać kolejkę. Dla zapisu naukowego polityka może być odwrotna: utrata klatki jest niedopuszczalna, więc zmniejsza się FPS albo zapisuje lokalnie.

RTP, RTCP i pakiety H.264#

RTP z RFC 3550 przenosi numer sekwencji i timestamp potrzebne do odtwarzania czasu oraz kolejności. Sam RTP nie gwarantuje dostarczenia ani nie rezerwuje pasma. RTCP przekazuje raporty jakości i synchronizacji.

RFC 6184 opisuje H.264 w RTP. Jednostka NAL może:

  • zmieścić się w pojedynczym pakiecie;
  • zostać połączona z innymi małymi jednostkami w aggregation packet;
  • zostać podzielona na fragmentation units, gdy przekracza MTU.

Pakiet IP nie powinien przekraczać MTU ścieżki. Fragmentacja IP zwiększa wrażliwość: utrata jednego fragmentu zwykle uniemożliwia odtworzenie całego datagramu. Packetizer powinien znać narzut IP/UDP/RTP/SRTP i pozostawić zapas dla tunelu.

Numer sekwencji wykrywa brak pakietu, a RTP timestamp nie jest zegarem ściennym. Do korelacji z telemetrią potrzebna jest jawna mapa czasu lub metadane o capture timestamp. W przeciwnym razie OSD może przedstawiać aktualną pozycję na obrazie sprzed kilkuset milisekund.

RFC 4585 rozszerza profil o wcześniejszy feedback RTCP, między innymi informacje pozwalające szybciej reagować na utratę. Mechanizm nie zastępuje congestion control i ma inne właściwości w połączeniu punkt-punkt niż w dużej grupie odbiorców.

UDP, ARQ i FEC#

UDP#

UDP dostarcza datagramy best effort. Brak retransmisji w transporcie może ograniczyć head-of-line blocking, ale aplikacja nadal musi reagować na przeciążenie zgodnie z wytycznymi RFC 8085. Nieograniczony strumień UDP może wypierać telemetrię i sam pogarszać kanał.

ARQ#

Automatic Repeat reQuest odzyskuje brakujące dane przez retransmisję. Działa dobrze, gdy RTT jest małe, strata umiarkowana, a pakiet zdąży wrócić przed deadline. Przy złym kanale retransmisje zwiększają obciążenie dokładnie wtedy, gdy pojemność spada. Stary pakiet wideo po terminie nie ma wartości.

FEC#

Forward Error Correction dodaje pakiety nadmiarowe pozwalające odtworzyć część strat bez round trip. Koszt jest płacony zawsze. Blokowe FEC wymaga zebrania danych i parytetów, więc rozmiar bloku wpływa na opóźnienie. Długi blok jest efektywny, ale wolniej się zamyka.

Hybryda#

Praktyczny system może używać umiarkowanego FEC dla strat typowych oraz selektywnego feedbacku dla ważnych elementów. Trzeba jednak kontrolować łączny narzut:

bitrate_radio = bitrate_video + RTP/IP + crypto + FEC + retransmissions

Jeżeli 4 Mbit/s wideo z 25% FEC i 10% średnich retransmisji jest liczone jako „4 Mbit/s”, budżet łącza oraz airtime są błędne.

Jitter buffer#

Pakiety nie docierają w idealnie równych odstępach. Jitter buffer porządkuje je i czeka na spóźnione elementy. GStreamer rtpjitterbuffer wykorzystuje timestampy oraz numerację, usuwa duplikaty i uznaje pakiety po określonym czasie za utracone.

Większy bufor zmniejsza liczbę pakietów uznanych za spóźnione, lecz wprost zwiększa latency. Ustawienie powinno wynikać z percentyli zmierzonego jitteru, nie z arbitralnych 200 ms. Dla łącza operatorskiego warto osobno raportować:

  • czas oczekiwania w jitter bufferze;
  • pakiety spóźnione;
  • pakiety utracone;
  • depth kolejki dekodera;
  • wiek klatki przy wyświetleniu.

Adaptacyjny bufor nie może tylko rosnąć. Potrzebna jest polityka redukcji po ustabilizowaniu kanału i limit maksymalny, po którego przekroczeniu stary obraz jest odrzucany.

Analogowe a cyfrowe FPV#

Analogowe FPV przekazuje sygnał wideo przez modulowany kanał bez kompresji międzyklatkowej. Obraz pogarsza się stopniowo wraz z SNR: pojawia się szum, zakłócenia i utrata synchronizacji. Tor może mieć małe opóźnienie, ale rozdzielczość, odporność na wielodrogowość i poufność są ograniczone.

Cyfrowe FPV koduje i pakuje obraz. Do pewnego progu odbiornik rekonstruuje obraz bardzo dobrze; poniżej progu występuje cliff effect, artefakty, zamrożenie albo utrata. FEC, diversity i adaptacja łagodzą granicę, ale nie usuwają jej.

Porównanie musi dotyczyć konkretnego end-to-end systemu. „Cyfrowe ma latency” i „analogowe nie ma latency” są uproszczeniami. Kamera analogowa i wyświetlacz również integrują obraz, a cyfrowy system zaprojektowany bez B-frames i nadmiernych buforów może być szybki oraz przewidywalny.

Łącze radiowe i airtime#

PHY rate nie jest bitrate wideo. Warstwa radiowa zużywa czas na preambuły, nagłówki, odstępy, potwierdzenia, contention, retransmisje i pakiety innych usług. Wi‑Fi o nominalnym MCS setek Mbit/s może mieć dużo mniejszy stabilny goodput przy słabym sygnale.

Wideo jest zwykle największym konsumentem airtime na UAV. Bez limitu może zagłodzić:

  • komendy i telemetrię MAVLink;
  • raporty jakości potrzebne do adaptacji;
  • synchronizację czasu;
  • ruch zarządzający i procedurę odzyskania.

Kolejki powinny mieć osobne klasy. Niski priorytet dużego strumienia nie rozwiązuje wszystkiego, jeśli pojedyncza ramka/aggregat długo zajmuje medium. W Wi‑Fi należy kontrolować WMM, DiffServ, wielkość agregacji i udział airtime.

OpenHD jest przykładem otwartego systemu łączącego cyfrowe wideo, telemetrię i sterowanie, wykorzystującego odpowiednio konfigurowane adaptery Wi‑Fi. Repozytorium i dokumentacja są wartościowym materiałem implementacyjnym, lecz zgodność konkretnego chipsetu, sterownika i trybu należy sprawdzać dla aktualnej wersji projektu.

Adaptacja do kanału#

System może zmieniać:

  • bitrate i QP encodera;
  • rozdzielczość lub FPS;
  • długość GOP;
  • procent FEC;
  • MCS/PHY i moc radia;
  • liczbę strumieni lub warstw;
  • priorytet ruchu.

Adaptacja musi uwzględniać opóźnienia pętli. Obniżenie bitrate kodera nie opróżnia natychmiast starej kolejki. Jeśli regulator patrzy na RSSI, a przeciążenie wynika z interferencji lub airtime, może wybrać złą reakcję.

Hierarchia reakcji bywa następująca:

dobry kanał: jakość nominalna
ostrzeżenie: mniej bitrate / więcej QP
słaby: mniej rozdzielczości lub FPS, krótsze deadline
krytyczny: tylko podstawowy obraz i telemetria
utrata: procedura niezależnego failsafe FC

Histereza i minimalny czas stanu zapobiegają oscylacji. Decyzja powinna używać goodput, PER, retransmisji, wieku klatek i głębokości kolejki — nie jednego RSSI.

Bezpieczeństwo transmisji#

Szyfrowanie chroni treść, ale tor potrzebuje też uwierzytelnienia i ochrony przed replay. RFC 3711 definiuje SRTP, które może zapewniać poufność, integralność wiadomości i ochronę przed powtórzeniami dla RTP oraz RTCP. Bez uwierzytelnienia fałszywy feedback może skłonić nadajnik do zmiany bitrate lub wysłania klatki odświeżającej.

Klucze nie powinny być wspólne dla całej floty ani zapisane jawnie w obrazie systemu. Potrzebna jest procedura provisioningu, rotacji, utraty terminala i zmiany właściciela. Szyfrowanie zwiększa narzut i koszt obliczeniowy, które należy zmierzyć na docelowym SoC.

Metadane pozostają widoczne zależnie od profilu i tunelu. Adresy, rozmiary pakietów i rytm transmisji mogą ujawniać istnienie strumienia nawet przy zaszyfrowanym payloadzie.

Telemetria i OSD#

OSD można generować:

  1. w kamerze/encoderze przed kompresją;
  2. jako osobną warstwę/metadane po stronie odbiornika;
  3. w wyświetlaczu z niezależnego kanału telemetrii.

Wypalenie OSD w obraz zapewnia zgodność z dowolnym odbiornikiem, ale trwale zmienia materiał i zużywa bitrate na ostre krawędzie tekstu. OSD po stronie ziemi jest elastyczne, lecz musi być zsynchronizowane z czasem capture. Pokazywanie aktualnej wysokości na opóźnionym obrazie może wprowadzać operatora w błąd.

Każda klatka lub grupa klatek powinna mieć identyfikator/czas możliwy do powiązania z logiem FC. Dla kamery termowizyjnej trzeba rozdzielić podgląd kolorowany od surowych/radiometrycznych danych pomiarowych.

Zasilanie, termika i EMC#

Encoder sprzętowy, SoC, pamięć i nadajnik mogą pobierać kilka–kilkanaście watów. Moc zależy od rozdzielczości, FPS, obciążenia radia i temperatury. Throttling termiczny zmniejsza FPS lub wydłuża kolejki, a nie zawsze pojawia się jako jawny błąd.

Projekt powinien rejestrować temperaturę SoC, częstotliwość taktowania, dropped frames i reset encodera. Bilans cieplny uwzględnia nieruchomy test na ziemi jako przypadek często gorszy od lotu z wymuszonym przepływem powietrza.

Nadajnik wideo może odczulać GNSS, RC lub inne radio. Szybkie interfejsy kamery promieniują harmoniczne. Separacja anten, filtry, ekranowanie i poprawne powroty prądu trzeba testować w finalnym montażu zgodnie z zasadami EMI/EMC.

Pomiar opóźnienia glass-to-glass#

Ping nie mierzy opóźnienia obrazu. Najprostszy test używa szybkiej kamery, która jednocześnie widzi zdarzenie i monitor odbiorczy:

  1. źródło wyświetla zmieniający się licznik lub zapala LED;
  2. kamera UAV rejestruje źródło;
  3. monitor pokazuje odebrany obraz;
  4. kamera pomiarowa filmuje źródło i monitor;
  5. różnica klatek daje glass-to-glass latency.

Przy 240 FPS rozdzielczość czasu wynosi około 4,17 ms. Trzeba zebrać setki zdarzeń, bo faza odświeżania monitora oraz kamera pomiarowa dodają kwantyzację. Raport powinien zawierać medianę i percentyle, nie jeden najlepszy wynik.

Wariant dokładniejszy wstawia capture timestamp do metadanych i mierzy prezentację fotodiodą, ale wymaga zsynchronizowanych zegarów. Timestamp z momentu wysłania pakietu pomija opóźnienie kamery i encodera.

Opóźnienie należy badać:

  • w statycznej i dynamicznej scenie;
  • z dobrym oraz pogarszanym kanałem;
  • po utracie pakietu i podczas recovery;
  • przy równoległej telemetrii;
  • po nagrzaniu systemu;
  • dla każdego wyświetlacza, bo TV może dodawać duży processing.

Obserwowalność#

Po stronie UAV:

  • capture FPS i dropped frames;
  • wiek bufora przy wejściu encodera;
  • bitrate chwilowy i rozmiar I-frame;
  • czas kodowania oraz QP;
  • długość kolejki packetizera;
  • pakiety/FEC/retransmisje;
  • temperatura i throttling.

Po stronie GCS:

  • braki numerów RTP i pakiety spóźnione;
  • jitter i depth bufora;
  • błędy depacketizera/dekodera;
  • liczba żądań odświeżenia;
  • decoded/rendered FPS;
  • wiek klatki przy prezentacji;
  • jakość radia w obu kierunkach.

Wspólny czas lub okresowa korelacja zegarów pozwala rozdzielić etapy. Bez tego „latency wzrosło” nie wskazuje, czy winny jest encoder, radio, jitter buffer czy compositor.

Plan testów#

Test pipeline bez radia#

Połącz nadajnik i odbiornik przewodem Ethernet lub kontrolowanym tunelem. Zmierz bazowe latency, bitrate, burst I-frame, użycie CPU/RAM i termikę. Wstrzyknij utratę, reorder, jitter i ograniczenie przepustowości narzędziem sieciowym.

Test RF#

Użyj tłumika i kontrolowanego kanału, a potem gotowych anten. Zmieniaj MCS, interferencję i ruch innych usług. Rejestruj goodput oraz airtime, nie tylko PHY rate.

Sceny testowe#

Zestaw powinien obejmować:

  • nieruchomą planszę ostrości;
  • drobny ruch liści/trawy;
  • szybki obrót i ruch translacyjny;
  • mało światła i krótką ekspozycję;
  • ostre krawędzie OSD;
  • przejście ciemne–jasne;
  • scenę termowizyjną, jeśli dotyczy.

Test awarii#

Wymuś utratę pakietów serią, przerwę łącza, restart odbiornika, reset encodera, brak kamery i przegrzanie. Sprawdź, czy system odzyskuje obraz bez restartowania flight controllera i czy operator widzi jawny stan „obraz nieaktualny”.

Kryteria odbioru#

obszar przykładowe kryterium
latency 99. percentyl glass-to-glass poniżej limitu dla profilu operatorskiego
świeżość brak wyświetlania klatki starszej niż limit; jawny blank/freeze indicator
recovery obraz wraca w określonym czasie po serii utrat lub reconnect
bitrate szczyt wraz z FEC i narzutem mieści się w goodput z marginesem
kolejki depth nie rośnie bez ograniczenia przy słabym kanale
jakość plansze i dynamiczne sceny spełniają ustalony próg czytelności
telemetria wideo nie przekracza deadline komend i statusów
bezpieczeństwo media i feedback są uwierzytelnione; replay odrzucany
termika brak throttlingu i resetu w najgorszym profilu temperatury
EMC aktywne wideo nie degraduje RC/GNSS poza przydzielony margines

Wymaganie „720p/60” bez latency, goodput i zachowania przy stracie nie jest kryterium odbioru. Użytkownik doświadcza kompletnego systemu, dlatego kwalifikacja musi kończyć się na ekranie i obejmować jednoczesną pracę pozostałych funkcji UAV.

Powiązane tematy#

Przypisy#

  1. ITU-T, Recommendation H.264: Advanced video coding for generic audiovisual services, https://www.itu.int/rec/T-REC-H.264 (dostęp: 15 sierpnia 2026).
  2. IETF, RFC 3550: RTP — A Transport Protocol for Real-Time Applications, https://www.rfc-editor.org/info/rfc3550/ (dostęp: 15 sierpnia 2026).
  3. IETF, RFC 6184: RTP Payload Format for H.264 Video, https://www.rfc-editor.org/info/rfc6184/ (dostęp: 15 sierpnia 2026).
  4. IETF, RFC 4585: Extended RTP Profile for RTCP-Based Feedback, https://www.rfc-editor.org/info/rfc4585/ (dostęp: 15 sierpnia 2026).
  5. IETF, RFC 3711: The Secure Real-time Transport Protocol, https://www.rfc-editor.org/info/rfc3711/ (dostęp: 15 sierpnia 2026).
  6. IETF, RFC 8085: UDP Usage Guidelines, https://www.rfc-editor.org/info/rfc8085/ (dostęp: 15 sierpnia 2026).
  7. Linux kernel documentation, V4L2 Video Capture Interface, https://docs.kernel.org/userspace-api/media/v4l/dev-capture.html (dostęp: 15 sierpnia 2026).
  8. GStreamer, rtpjitterbuffer, https://gstreamer.freedesktop.org/documentation/rtpmanager/rtpjitterbuffer.html (dostęp: 15 sierpnia 2026).
  9. OpenHD, repozytorium projektu, https://github.com/OpenHD/OpenHD (dostęp: 15 sierpnia 2026; implementację należy odnosić do używanej wersji i licencji projektu).

Powiązane tematy

Wi‑Fi jako łącze UAVWi‑Fi jako współdzielone łącze IP UAV: tryby AP/station/mesh, budżet radiowy, airtime, MCS i retransmisje, QoS, transport telemetrii oraz wideo, zabezpieczenia, anteny, obserwowalność, failsafe i testy end-to-end.Wi‑Fi, LTE i 5G jako łącze UAVAktualizacja koncepcji sterowania przez GSM: stabilizacja zawsze lokalna, a sieć komórkowa przenosi misję, telemetrię i opcjonalnie wideo.Budżet łącza radiowego UAVPraktyczna metodyka budżetu łącza UAV: jednostki dB/dBm/dBi, EIRP, strata wolnej przestrzeni, horyzont i Fresnel, czułość z bilansu szumu, interferencja, polaryzacja, anteny w kadłubie, margines statystyczny, uplink/downlink oraz plan pomiarów.Systemy RC dla UAVArchitektura nowoczesnego łącza RC: packet rate, opóźnienie, czułość, LQ/RSSI/SNR, telemetria i zachowanie po utracie ramek.Kamera termowizyjna UAVIntegracja kamery termowizyjnej UAV od fizyki promieniowania i parametrów detektora przez optykę, radiometrię, emissivity, atmosferę, NUC/FFC, gimbal i interfejs wideo po kalibrację, geolokalizację oraz kryteria pomiarowe.EMI/EMC w kontrolerze lotuEMI/EMC flight controllera jako problem obwodów i pól: pętle di/dt, węzły dv/dt, powroty prądów, sprzężenia przewodzone i promieniowane, ochrona portów oraz plan testów przedzgodnościowych.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Sieci mesh dla UAVSieć mesh UAV od wspólnego medium i kosztu relay przez 802.11s, routing reaktywny/proaktywny, metryki ETX/airtime, konwergencję w ruchu, gatewaye, multicast i QoS po uwierzytelnianie routingu, obserwowalność i testy topologii.

Źródła z centralnego rejestru

  1. ITU-T H.264: Advanced video coding for generic audiovisual services [standard kodeka]
  2. IETF RFC 3550: RTP — A Transport Protocol for Real-Time Applications [standard internetowy]
  3. IETF RFC 6184: RTP Payload Format for H.264 Video [standard internetowy]
  4. IETF RFC 4585: RTP/AVPF — RTCP-Based Feedback [standard internetowy]
  5. IETF RFC 3711: Secure Real-time Transport Protocol [standard internetowy]
  6. IETF RFC 8085: UDP Usage Guidelines [Best Current Practice]
  7. Linux kernel documentation: V4L2 Video Capture Interface [dokumentacja projektu]
  8. GStreamer: rtpjitterbuffer documentation [dokumentacja projektu]
  9. OpenHD — open source digital video, telemetry and control link [repozytorium open source]
  10. Eric Cheng, „Drony. Tajniki zdjęć i filmów lotniczych” [książka]
  11. Sumit Sharma, „Drone Development from Concept to Flight” [książka]