Geofencing UAV

Geofence jest maszynowo interpretowaną granicą przestrzeni, w której UAV może albo nie może się znaleźć. Jego użyteczność zależy nie tylko od geometrii wielokąta, lecz od jakości pozycji, definicji wysokości, aktualności danych, dynamiki statku i jednoznacznej reakcji po zbliżeniu do granicy. Sam test inside = true nie jest jeszcze funkcją bezpieczeństwa.

W systemie produkcyjnym trzeba rozdzielić co najmniej trzy rzeczy: informację o strefach geograficznych i ograniczeniach prawnych, ograniczenia zaplanowanej misji oraz pokładową barierę egzekwowaną przez autopilot. Mogą wykorzystywać podobne dane geometryczne, ale mają inne źródła, odpowiedzialność i skutki błędu. Pokładowy geofence nie jest zezwoleniem na lot, a zgodność planu z mapą nie gwarantuje, że statek nie przekroczy granicy pod wpływem wiatru, błędu estymacji lub niewłaściwej reakcji failsafe.

Spis treści#

Trzy różne warstwy
Model zagrożeń i wymagania
Rodzaje granic
Semantyka inclusion i exclusion
Układ współrzędnych
Wysokość i odniesienie pionowe
Punkt w wielokącie
Odległość od granicy
Footprint i niepewność pozycji
Predykcja naruszenia
Margines dynamiczny
Sprawdzanie planu misji
Egzekwowanie podczas lotu
Reakcja na naruszenie
Powrót świadomy geofence
Utrata pozycji
Granice czasowe i dynamiczne
Format i dystrybucja danych
MAVLink Mission Protocol
Integralność i cyberbezpieczeństwo
Implementacje PX4 i ArduPilot
Fixed wing VTOL i inne platformy
Logowanie i obserwowalność
SITL HIL i fault injection
Kryteria odbioru
Typowe błędy
Powiązane tematy
Przypisy

Trzy różne warstwy#

Informacja geograficzna i prawna#

Strefa geograficzna UAS jest informacją publikowaną przez właściwy organ lub dostawcę danych. Może zawierać zakaz, ograniczenie wysokości, warunek uzyskania zgody, okno czasowe albo inne wymaganie. Jest częścią procesu przygotowania operacji. Jej brak w pamięci kontrolera nie usuwa obowiązku sprawdzenia aktualnych zasad, NOTAM, ograniczeń lokalnych i warunków zezwolenia.

Geo-awareness informuje pilota lub system o położeniu względem takich stref. Może ostrzec, lecz nie musi bezpośrednio ograniczać sterowania. EASA opisuje strefy geograficzne UAS i cyfrowe publikowanie ich danych w ramach przepisów europejskich; szczegóły prawne i źródło obowiązujące dla konkretnej operacji trzeba sprawdzać w chwili planowania.[7]

Walidacja planu#

Planner może odrzucić waypoint poza dopuszczalnym obszarem, odcinek przecinający exclusion zone albo wysokość naruszającą floor/ceiling. Jest to kontrola przed lotem. Nie zabezpiecza przed ręcznym lotem, dryfem, zmianą planu w powietrzu, błędem pozycji ani niewykonalnym zakrętem między poprawnymi punktami.

Pokładowe egzekwowanie#

Autopilot cyklicznie porównuje estymowany stan i przewidywaną trajektorię z aktywną granicą. Może ograniczać setpoint, zatrzymać ruch, zawrócić, uruchomić Return albo Land. To mechanizm czasu rzeczywistego, zależny od estymatora i dostępnych aktuatorów.

Te warstwy powinny być połączone, ale niezależnie identyfikowalne:

źródło stref prawnych → planowanie operacji → zatwierdzony obszar
                                            ↓
operator/GCS → walidacja misji → fence dataset → autopilot
                                            ↓
state estimator → predykcja → fence monitor → limiter/failsafe

W logu trzeba móc odtworzyć, która wersja danych obowiązywała, czy planner tylko ostrzegł, czy autopilot rzeczywiście miał fence uzbrojony i jaka akcja była skonfigurowana.

Model zagrożeń i wymagania#

Przed wyborem formatu pliku należy zdefiniować niepożądane zdarzenie. Przykłady to wyjście poza teren prób, wlot nad ludzi, przekroczenie sufitu, wejście w strefę przeszkody, utrata statku po zerwaniu łącza albo niekontrolowane lądowanie tuż za granicą. Każde prowadzi do innej reakcji.

Wymaganie „UAV nie przekroczy wielokąta” jest niepełne. Potrzebne są co najmniej:

źródło i wersja geometrii;
konwencja punktów leżących dokładnie na granicy;
pionowy zakres obowiązywania;
wymagany poziom jakości pozycji;
footprint statku i ładunku;
maksymalna prędkość, wiatr, opóźnienie i droga zatrzymania;
akcja przed naruszeniem i po naruszeniu;
zachowanie po utracie pozycji albo danych fence;
reguła restartu i ponownego uzbrojenia;
kryteria testowe oraz stan raportowany do GCS.

Zagrożeniem są nie tylko błędy algorytmu. Strefa może być nieaktualna, odwrócona, mieć niewłaściwe jednostki, przejść przez południk 180°, zawierać samoprzecięcie albo używać wysokości nad elipsoidą, gdy operator wpisał AGL. Operator może wysłać tylko połowę listy, a łącze zerwać się w trakcie aktualizacji. Odbiornik GNSS może zgłosić precyzyjną, ale błędną pozycję. System bezpieczeństwa musi traktować te przypadki jako jawne stany.

Rodzaje granic#

Cylinder wokół home#

Najprostszy fence ogranicza promień poziomy względem punktu home oraz wysokość minimalną i maksymalną. Test odległości w lokalnym układzie ENU/NED jest tani. Cylinder nadaje się do małych poligonów prób, ale nie odwzorowuje nieregularnego terenu ani korytarza.

Okrąg i wielokąt inclusion#

Inclusion zone definiuje przestrzeń dozwoloną. Okrąg opisuje środek i promień. Wielokąt jest listą wierzchołków na powierzchni poziomej. Ich pionowe rozwinięcie bywa nieskończone albo ograniczone osobnym floor/ceiling.

Okrąg i wielokąt exclusion#

Exclusion zone jest przeszkodą przestrzenną: statek ma pozostać na zewnątrz. Może chronić obiekt, pas ruchu naziemnego, maszt, zabudowę lub część obszaru testowego. Nie należy zakładać, że exclusion ma zawsze pierwszeństwo wyłącznie dlatego, że jest wysłane później; kolejność i logika kombinacji muszą być określone przez model danych.

Pas wysokości#

Floor i ceiling ograniczają współrzędną pionową. Płaski sufit względem home jest łatwy, lecz na terenie o dużej deniwelacji nie odpowiada stałej wysokości AGL. Fence zależny od terenu potrzebuje DEM lub pomiaru wysokości nad gruntem i osobnej polityki braku danych.

Korytarz#

Korytarz można zapisać jako bufor wokół polilinii albo ciąg nachodzących na siebie wielokątów/okręgów. Jego bezpieczna szerokość musi obejmować błąd prowadzenia, footprint, wiatr i promień zakrętu. Wąski korytarz, przez który fixed-wing nie może przelecieć bez naruszenia, jest błędem planu, nie wyzwaniem dla regulatora.

Granica wolumetryczna#

Pełny geofence 3D może mieć różne przekroje na wysokościach, nachylone ściany lub powierzchnię zależną od czasu. Typowe autopiloty obsługują prostsze pryzmaty i oddzielne limity wysokości. GCS nie powinien spłaszczać złożonego wolumenu bez ostrzeżenia o utracie semantyki.

Semantyka inclusion i exclusion#

Dla punktu poziomego p można zapisać dopuszczalność:

allowed(p) = inside_allowed_union(p) AND NOT inside_excluded_union(p)

Nie wszystkie implementacje używają jednak unii dla wielu inclusion zones. ArduPilot dokumentuje, że wiele obszarów inclusion musi się nakładać, a pozycja jest poprawna w ich części wspólnej.[4] To semantyka przecięcia:

allowed(p) = I1(p) AND I2(p) AND ... AND NOT (E1(p) OR E2(p) OR ...)

Różnica jest zasadnicza. Dwa rozłączne wielokąty inclusion oznaczają w modelu unii dwa dozwolone pola, a w modelu przecięcia pusty zbiór. Importer musi znać regułę firmware i przed wysłaniem obliczyć, czy wynik nie jest pusty.

Potrzebna jest też kolejność pionowa. Przykładowo obszar może być zabroniony tylko od 0 do 120 m AGL, a przelot nad nim dozwolony na innej wysokości. Jeśli protokół nie potrafi przenieść takiej semantyki, należy zastosować konserwatywne przybliżenie albo odrzucić import; ciche usunięcie wysokości jest niebezpieczne.

Układ współrzędnych#

Wierzchołki stref są często przechowywane jako szerokość i długość geograficzna. Testy geometryczne wygodniej i poprawniej wykonywać w lokalnej płaszczyźnie stycznej dla niewielkiego obszaru:

latitude/longitude/height
        ↓ geodetic to ECEF
      X,Y,Z ECEF
        ↓ ECEF to local tangent plane
      east,north,up

Proste mnożenie różnicy długości geograficznej przez stałą liczbę metrów na stopień daje błąd zależny od szerokości. Dla małego pola można użyć lokalnego ENU/NED z poprawną transformacją geodezyjną. Dla dużych obszarów trzeba uwzględnić krzywiznę Ziemi, wybór geodezyjnych odcinków granicy i projekcję kartograficzną.

Szczególne przypadki:

wielokąt przechodzący przez południk 180° wymaga unwrap długości;
obszar blisko bieguna źle zachowuje się w zwykłych projekcjach lokalnych;
identyczne pierwsze i ostatnie wierzchołki mogą być wymagane albo zabronione zależnie od formatu;
kolejność zgodna lub przeciwna do ruchu wskazówek może oznaczać zewnętrzną obwiednię albo otwór;
samoprzecięcia dają niejednoznaczne wnętrze;
duplikaty i krawędzie o zerowej długości pogarszają obliczenia odległości.

Walidator powinien normalizować tylko te cechy, których znaczenie jest pewne. Nie wolno „naprawiać” samoprzecięcia automatycznie bez raportu, bo wynik może nie odpowiadać intencji operatora.

Więcej o ECEF, NED, ENU i transformacjach opisuje artykuł Układy współrzędnych w UAV.

Wysokość i odniesienie pionowe#

Słowo „100 metrów” nie definiuje granicy pionowej. Możliwe odniesienia to:

wysokość względem punktu home;
AGL względem terenu pod UAV;
AMSL/MSL według modelu geoidy;
wysokość elipsoidalna GNSS;
lokalna współrzędna z estymatora;
wysokość względem punktu startu misji.

Między wysokością elipsoidalną a ortometryczną występuje separacja geoidy. Barometr ma arbitralny offset i dryf. Terrain following używa DEM lub rangefindera, których błędy są inne niż błędy pozycji GNSS. Fence musi zapisać frame oraz politykę konwersji.

Dla sufitu można konserwatywnie uwzględnić niepewność:

h_command_max = h_ceiling - margin_vertical
margin_vertical = k · sigma_h + tracking_error + vehicle_extent + reserve

Analogicznie floor przesuwa się do góry. Jeżeli źródło wysokości zmienia się podczas lotu, stan z nie powinien skoczyć przez granicę. Potrzebny jest continuity offset albo kontrolowane przejście. Fence monitor powinien odróżnić rzeczywiste naruszenie od resetu estymatora, lecz nie może ignorować długotrwałej niezgodności.

Punkt w wielokącie#

Dwa popularne algorytmy to ray casting i winding number. Dla prostego wielokąta ray casting liczy przecięcia półprostej z krawędziami. Parzysta liczba oznacza zewnętrze, nieparzysta wnętrze. Implementacja musi ustalić zachowanie dla wierzchołka, poziomej krawędzi i punktu dokładnie na odcinku.

Przykładowy pseudokod po wcześniejszym przeliczeniu do lokalnego east,north:

function classify(point, polygon, epsilon):
    for edge in polygon.edges:
        if distance_to_segment(point, edge) <= epsilon:
            return BOUNDARY

    crossings = 0
    for edge(a, b) in polygon.edges:
        if edge_straddles_horizontal_ray(a, b, point.north):
            e_cross = interpolate_east_at_north(a, b, point.north)
            if e_cross > point.east:
                crossings += 1

    return INSIDE if crossings is odd else OUTSIDE

Klasa BOUNDARY nie powinna być od razu zamieniana w inside bez kontekstu. Dla inclusion granica może być traktowana jako niebezpieczna i pomniejszona o margines. Dla exclusion granica również powinna być niedozwolona i powiększona. Ta asymetria prowadzi do reguły: wynik ma zapewnić dodatni clearance, a nie tylko poprawną topologię.

Obliczenia powinny używać typu o wystarczającej precyzji. Lat/lon w stopniach zapisane w float32 mogą stracić rozdzielczość potrzebną na poziomie metrów. MAVLink często reprezentuje współrzędne globalne jako stopnie skalowane przez 1e7 w polach całkowitych, co ogranicza błąd serializacji; dalsza transformacja nadal wymaga poprawnej arytmetyki.[6]

Odległość od granicy#

Do predykcji potrzebna jest podpisana odległość, nie tylko inside/outside. Dla odcinka a-b:

t = clamp(dot(p-a, b-a) / dot(b-a, b-a), 0, 1)
q = a + t · (b-a)
d = norm(p-q)

Minimum po krawędziach daje odległość do wielokąta. Znak można nadać na podstawie klasyfikacji. Dla inclusion dodatnia wartość może oznaczać clearance wewnątrz, a dla exclusion clearance na zewnątrz. Trzeba utrzymać jedną konwencję w całym systemie.

Dla okręgu o środku c i promieniu r:

clearance_inclusion = r - norm(p-c)
clearance_exclusion = norm(p-c) - r

W 3D clearance jest minimum z granicy poziomej i pionowej, chyba że model reprezentuje faktyczną odległość euklidesową do bryły. Dla sterowania zwykle ważniejszy jest osobny czas do naruszenia poziomego i pionowego niż jedna liczba.

Gradient signed distance wskazuje kierunek zwiększania clearance. W narożniku może być nieciągły. Limiter nie powinien generować gwałtownych zmian yaw/velocity wyłącznie z powodu przełączenia najbliższej krawędzi.

Footprint i niepewność pozycji#

Pozycja estymatora opisuje punkt referencyjny, zwykle środek IMU lub body frame. Statek ma rozmiar, obracające się śmigła, anteny, ładunek i błąd montażu. Punkt może pozostać w strefie, gdy końcówka skrzydła ją przekroczy.

Bezpieczne przekształcenie geometrii jest następujące:

inclusion zone pomniejszyć o footprint i margines;
exclusion zone powiększyć o footprint i margines.

Dla kołowego przybliżenia wystarcza bufor o promieniu r_vehicle. Dla fixed-wing konserwatywny okrąg opisany na płatowcu bywa zbyt duży w wąskim korytarzu; można stosować footprint zależny od yaw, ale wtedy kwalifikacja musi objąć błędy orientacji i szybkie obroty.

Pozioma niepewność pozycji jest macierzą covariance, nie promieniem idealnego koła. Margines w kierunku jednostkowej normalnej n do granicy można obliczyć jako:

sigma_normal = sqrt(n^T · P_position · n)
margin_uncertainty = k · sigma_normal

k wynika z przyjętego poziomu pokrycia i modelu błędu. Estymator może mieć niegaussowskie błędy, multipath albo skok po przełączeniu źródła, dlatego sama covariance nie wystarcza. Trzeba uwzględnić testy innowacji, fix type, wiek korekt RTK, spójność źródeł i maksymalny zaobserwowany błąd z prób.

Całkowity bufor może być sumą lub bardziej formalną kompozycją:

margin = vehicle_extent
       + map_accuracy
       + k · position_uncertainty
       + tracking_allowance
       + latency_allowance
       + operational_reserve

Mapa stref też ma dokładność. Granica pochodząca z uproszczonego rysunku nie staje się centymetrowa dlatego, że UAV używa RTK FIX.

Predykcja naruszenia#

Reakcja dopiero po przekroczeniu granicy jest za późna. Monitor powinien przewidywać ruch w horyzoncie obejmującym wykrycie, decyzję, zmianę setpointu, odpowiedź regulatora i dynamikę statku.

Najprostsza predykcja stałej prędkości:

p_pred(t) = p_now + v_ground · t

Jest użyteczna na krótki horyzont, ale nie uwzględnia przyspieszenia, zakrętu i limitu jerk. Lepszy monitor propaguje referencyjny model dynamiki z bieżącym setpointem i ograniczeniami. Dla fixed-wing potrzebny jest łuk zakrętu, prędkość względem powietrza i wiatr; zatrzymanie w miejscu nie jest możliwe.

Czas do granicy dla lokalnie płaskiej krawędzi o inward normal n i clearance d:

closing_speed = -dot(v_ground, n)
time_to_boundary = d / closing_speed, gdy closing_speed > 0

Wynik trzeba ograniczyć, gdy statek porusza się równolegle lub od granicy. Dla narożników i zakrzywionej trajektorii należy sprawdzić próbki całego przewidywanego toru, a nie tylko punkt końcowy.

Monitor powinien publikować co najmniej clearance, time_to_boundary, predicted_breach, position_quality, fence_version i proponowaną akcję. Dzięki temu log rozróżnia brak marginesu od faktycznego naruszenia.

Margines dynamiczny#

Droga potrzebna do zatrzymania ruchu w kierunku granicy zależy od prędkości, maksymalnego bezpiecznego opóźnienia, jerk, wiatru i całkowitego opóźnienia systemu. Przy uproszczeniu stałego opóźnienia:

d_stop = v_closing · t_latency + v_closing² / (2 · a_brake)

Do t_latency należą: okres estymatora, okres fence monitora, kolejka komunikatów, okres kontrolera pozycji, odpowiedź napędu i czas rozpoznania warunku. Jeśli setpoint przychodzi z companion computera, trzeba dodać jego watchdog i transmisję.

Przy limicie jerk narastanie opóźnienia wydłuża drogę. Dla testu odbiorczego należy symulować dokładny profil regulatora albo zmierzyć najgorszy przypadek przy maksymalnej masie i niekorzystnym wietrze.

Margines dynamiczny powinien rosnąć z closing speed. Stałe 5 m może być nadmierne w wolnym locie wewnątrz hali i niewystarczające dla szybkiego fixed-wing. Praktyczny limiter zaczyna redukować składową prędkości prostopadłą do granicy, pozostawiając ruch styczny, o ile nie prowadzi on do narożnika.

Sprawdzanie planu misji#

Walidacja misji powinna obejmować więcej niż waypointy:

Każdy punkt nawigacyjny musi należeć do dozwolonego wolumenu z wymaganym marginesem.
Każdy odcinek lub planowana krzywa między punktami musi być sprawdzona pod kątem przecięcia z exclusion i opuszczenia inclusion.
Zakręty muszą mieścić się w granicy przy zadanej prędkości, promieniu i wietrze.
Profile wznoszenia i opadania nie mogą przekraczać floor/ceiling.
Polecenia zmieniające prędkość, wysokość, home albo tryb muszą zostać uwzględnione w kolejnych segmentach.
Return route, miejsce lądowania awaryjnego i loiter także muszą być wykonalne.
Misja nie może zależeć od przejścia przez obszar, który po zastosowaniu marginesów ma zerową szerokość.

Przy planie waypointowym poprawne końce segmentu nie dowodzą poprawności łuku. Spline może wyjść poza wielokąt. Fixed-wing z dużym promieniem zakrętu może przestrzelić punkt po zewnętrznej. Multirotor może być zniesiony przez wiatr przy ograniczonym thrust reserve.

Walidator powinien podawać konkretny konflikt: identyfikator segmentu, fence, minimalny clearance, frame wysokości i użyte założenia dynamiki. Ogólne „mission invalid” utrudnia operatorowi usunięcie przyczyny.

Egzekwowanie podczas lotu#

Pokładowy monitor działa na stanie estymowanym, nie na surowym GNSS. Powinien mieć określony okres wykonania i deadline. Strefy używane do działania czasu rzeczywistego należy przygotować wcześniej: przeliczyć do odpowiedniej reprezentacji, sprawdzić geometrię i atomowo aktywować.

Przykładowa maszyna stanów:

DISABLED
  → ARMED_CLEAR
  → APPROACHING
  → LIMITING
  → BREACHED
  → RECOVERING
  → CLEAR

każdy stan → POSITION_INVALID / FENCE_INVALID → configured failsafe

Histereza zapobiega migotaniu między CLEAR i BREACHED, gdy pozycja oscyluje na granicy. Nie może jednak tworzyć obszaru, w którym statek pozostaje formalnie poza fence bez reakcji. Można użyć osobnego progu wejścia, wyjścia i minimalnego czasu stabilnej poprawności.

Limiter powinien oddziaływać na dozwoloną komendę, nie fałszować pozycji. Dla prędkości rozkłada się setpoint na składową normalną i styczną do granicy. Składowa prowadząca na zewnątrz jest redukowana wraz ze spadkiem clearance; ruch do wnętrza pozostaje dostępny.

W trybie ręcznym operator powinien dostać wyraźny komunikat i przewidywalne ograniczenie. W trybie automatycznym planner może wykonać replan, ale prosty limiter w FC nadal stanowi ostatnią warstwę. Utrata GCS nie może wyłączyć fence.

Reakcja na naruszenie#

Nie istnieje jedna zawsze poprawna akcja. Możliwe reakcje to:

tylko raportowanie podczas testów naziemnych;
ograniczenie komendy przed granicą;
zatrzymanie lub hold dla multirotora;
lot do bezpiecznego punktu wewnątrz;
Return po trasie respektującej fence;
Land w aktualnym lub wyznaczonym miejscu;
kontrolowany loiter i oczekiwanie na decyzję;
zakończenie misji i przejście do osobnego contingency plan.

Return może być złą reakcją, jeśli prosta do home przecina exclusion. Land może być złą reakcją nad wodą, drogą albo ludźmi. Hold nie jest trwały przy kończącej się baterii. Fixed-wing nie może zatrzymać się i może potrzebować natychmiastowego zakrętu o kierunku zależnym od geometrii.

Akcję należy wybierać na etapie oceny ryzyka i zapisać wraz z fence. Autopilot musi mieć fallback, gdy preferowana reakcja jest niewykonalna. Przykład:

if safe_return_route_exists and energy_margin_ok:
    execute_return_route()
else if approved_landing_site_reachable:
    land_at_site()
else:
    execute_platform_specific_contingency()

„Najbliższy punkt wewnątrz” nie zawsze jest bezpiecznym celem: może leżeć tuż za przeszkodą albo wymagać przejścia przez exclusion. Punkt recovery powinien być osiągalny po dozwolonej trajektorii i zawierać zapas do granic.

Powrót świadomy geofence#

Klasyczny RTL po prostej do home może przeciąć zakazany wielokąt. System geofence-aware powinien znaleźć trasę wewnątrz inclusion i poza exclusion, a następnie sprawdzić jej wykonalność dynamiczną. PX4 dokumentuje planowanie krótszej poziomej ścieżki powrotnej omijającej obsługiwane strefy dla odpowiednich wariantów Return. Dokumentacja jednocześnie zaznacza, że błąd śledzenia i wiatr nie pozwalają traktować tego jako absolutnej gwarancji niewyjścia poza granicę.[2]

Planner powrotu musi rozważyć:

bieżący punkt, który może już być niedozwolony;
ostatnią znaną poprawną pozycję;
home i alternatywne miejsca lądowania;
wysokość przeszkód i fence pionowy;
energię potrzebną na objazd;
minimalny promień zakrętu i kierunek loiter;
zmianę strefy podczas powrotu;
niepewność pozycji oraz mapy.

Jeżeli statek już naruszył strefę, najkrótszy wektor do granicy niekoniecznie prowadzi do spójnego dozwolonego obszaru. Przy wielu inclusion zones albo otworach trzeba znaleźć komponent przestrzeni zawierający punkt recovery. Gdy geometrii nie da się rozwiązać, zachowanie awaryjne musi być zdefiniowane wcześniej.

Utrata pozycji#

Fence oparty na globalnych współrzędnych nie działa wiarygodnie bez pozycji. Brak GNSS nie zawsze oznacza brak pozycji: VIO, optical flow, INS wspomagany prędkością lub lokalny SLAM mogą przez pewien czas utrzymać stan. Warunkiem jest znana transformacja między lokalnym odom a globalnym frame fence i monitorowana niepewność.

Stany jakości mogą wyglądać tak:

Stan	Znaczenie	Przykładowa reakcja
valid	pozycja i covariance w wymaganym limicie	normalne egzekwowanie
degraded	rosnąca niepewność, nadal poniżej limitu	zwiększenie marginesu, ograniczenie prędkości
local only	ciągła lokalna odometria, niepewna globalna kotwica	czasowo utrzymać lokalny bufor i wykonać contingency
invalid	brak wiarygodnego położenia względem fence	odrębny position-loss failsafe

Nie wolno zamieniać invalid na „inside”. Równie błędne jest natychmiastowe uznanie każdej utraty pojedynczego odbiornika GNSS za breach, jeśli system ma kwalifikowane źródło zapasowe. Decyzja należy do monitora integralności estymatora.

Po odzyskaniu GNSS może wystąpić skok globalnej pozycji. Fence monitor powinien otrzymać zdarzenie resetu estymatora i ocenić nowy stan, ale nie ignorować granicy przez arbitralne kilka sekund. Jeśli obie hipotezy pozycji są rozbieżne, bezpieczna trajektoria powinna uwzględnić ich obwiednię do czasu rozstrzygnięcia.

Szczegóły degradacji opisują Dead reckoning UAV i Problemy GNSS w UAV.

Granice czasowe i dynamiczne#

Strefa może obowiązywać od valid_from do valid_until, cyklicznie albo zostać zmieniona w trakcie operacji. Zegar staje się elementem safety. Potrzebne są:

źródło UTC i oszacowanie niepewności czasu;
jawna strefa czasowa danych wejściowych;
reguła zachowania przy braku synchronizacji;
wersja i czas pobrania danych;
ostrzeżenie przed wygaśnięciem;
zakaz cichego przedłużania ważności.

Aktywacja nowej strefy nie może uwięzić UAV bez planu. Przed atomowym przełączeniem trzeba sprawdzić bieżącą pozycję i zaplanować reakcję, jeżeli stanie się niedozwolona. GCS powinien wyświetlić konflikt przed wysłaniem, ale autopilot nadal musi go obsłużyć.

Dynamiczny geofence może otaczać poruszający się obiekt albo przesuwać korytarz. Wymaga identyfikatora źródła, timestampu, predykcji ruchu i timeoutu. Po utracie aktualizacji nie można utrzymywać ostatniej pozycji celu bez końca. Zależnie od zastosowania strefę rozszerza się o niepewność predykcji albo przechodzi do bezpiecznego trybu.

Format i dystrybucja danych#

Model danych powinien zawierać co najmniej:

fence_set_id
revision
source
created_at / valid_from / valid_until
coordinate_reference_system
vertical_reference
geometry type + vertices/radius
inclusion/exclusion
floor/ceiling + units
accuracy / uncertainty
priority or combination rule
required action
checksum/signature

GeoJSON dobrze przenosi geometrię 2D, ale nie definiuje automatycznie wszystkich semantyk lotniczych, pionowych i czasowych. KML ma podobny problem. Format wymiany z organem może być bogatszy niż format pokładowy. Konwerter jest wtedy częścią systemu bezpieczeństwa i wymaga testów na utratę pól.

Pipeline powinien zachować pochodzenie:

authoritative dataset
  → parser + schema validation
  → semantic validation
  → coordinate/vertical conversion
  → conservative simplification
  → target firmware representation
  → read-back + hash comparison

Uproszczenie wielokąta zmniejsza liczbę wierzchołków, ale może przesunąć granicę. Dla exclusion aproksymacja musi pozostać po bezpiecznej stronie, czyli nie może usunąć zakazanego fragmentu. Dla inclusion nie może dodać obszaru. Ogólny Douglas–Peucker bez kontroli kierunku nie daje takiej gwarancji.

MAVLink Mission Protocol#

MAVLink Mission Protocol obsługuje zestawy elementów misji, fence i rally jako osobne typy. Transfer jest sekwencją z potwierdzeniami, numerami elementów oraz wynikiem operacji.[6] GCS nie powinien mieszać aktywnej misji z fence ani zakładać, że sukces wysłania pierwszych pakietów oznacza aktywację całości.

Bezpieczny upload:

GCS przygotowuje i lokalnie waliduje pełny zestaw.
Rozpoczyna transfer deklarując typ i liczbę elementów.
Autopilot żąda kolejnych pozycji i zapisuje je w staging area.
Każdy element jest walidowany pod względem typu, indeksu, liczb i limitów.
Dopiero kompletna, poprawna lista zostaje atomowo aktywowana.
Autopilot zwraca wynik; GCS pobiera dane z powrotem i porównuje semantykę.
Log zapisuje revision/hash aktywnego zestawu.

Timeout albo rozłączenie powinno pozostawić poprzedni aktywny fence. Nie można aktywować prefiksu listy. Zduplikowane pakiety muszą być idempotentne, a pakiet z niewłaściwym mission type odrzucony.

Komendy wspólnego dialectu MAVLink obejmują m.in. punkty powrotu fence, wierzchołki wielokąta inclusion/exclusion i okręgi. Konkretna obsługa zależy od autopilota. GCS powinien odczytać capabilities lub znać profil wersji firmware, zamiast zakładać pełną obsługę każdego typu.

Integralność i cyberbezpieczeństwo#

Fence jest konfiguracją wpływającą na tor lotu. Atakujący albo przypadkowy błąd może usunąć exclusion, przesunąć strefę, ustawić ogromny promień, zmienić akcję na report-only albo wgrać dane po zatwierdzeniu planu.

Kontrole powinny obejmować:

autoryzację roli mogącej zmieniać fence;
podpisywanie MAVLink 2 tam, gdzie profil systemu tego wymaga;
ochronę kluczy i procedurę ich rotacji;
potwierdzenie na GCS przy zmianie w locie;
allowlistę typów i limitów parametrów;
licznik wersji odporny na rollback;
hash konfiguracji w logu i raporcie przedstartowym;
blokadę uzbrojenia przy braku wymaganego fence;
read-back po transferze;
alert przy każdej zmianie stanu aktywności.

Podpis transportowy nie dowodzi prawdziwości danych źródłowych. Potrzebny jest łańcuch zaufania od publikacji strefy, przez konwersję, aż po aktywną reprezentację. Równie ważna jest dostępność: uszkodzony plik lub brak sieci nie powinien prowadzić do cichego lotu bez obowiązkowej granicy.

Implementacje PX4 i ArduPilot#

PX4 udostępnia konfigurację geofence i powiązane zachowanie Return. Aktualna dokumentacja projektu opisuje parametry ograniczeń, strefy inclusion/exclusion i planowanie powrotu z uwzględnieniem obsługiwanej geometrii.[1][2] Dokładne limity i funkcje należy sprawdzać dla wersji firmware zainstalowanej na konkretnym kontrolerze. Dokumentacja main może wyprzedzać wydanie używane w sprzęcie.

PX4 zaznacza ograniczenie liczby wierzchołków używanych przez geofence-aware Return; na aktualnej stronie Return wskazano łącznie 99 wierzchołków, przy czym okrąg jest liczony jak osiem.[2] Jest to właściwość implementacji, nie cecha geofencingu jako takiego. Konwerter powinien znać limit docelowego builda i odrzucić albo bezpiecznie uprościć zbyt złożoną geometrię.

ArduPilot obsługuje wielokątne i okrągłe inclusion/exclusion fences oraz może łączyć je z cylindrem wokół home i limitami wysokości. Dokumentacja polygon fence podaje limit do 70 punktów dla opisywanej konfiguracji i rekomenduje promienie nie mniejsze niż 30 m; podkreśla również zależność od dobrej pozycji GPS i działania zabezpieczeń EKF.[4] Wartości parametrów FENCE_TYPE, FENCE_ACTION i FENCE_MARGIN są wersjozależne i trzeba je sprawdzić w referencji właściwej dla używanego wydania.[5]

Różnice między firmware obejmują:

sposób kombinowania wielu inclusion zones;
obsługiwane typy geometrii;
maksymalną liczbę wierzchołków;
pionowe frame;
możliwość zmiany w locie;
akcje po breach;
planowanie trasy Return;
wymagania MAVLink 1/2 i GCS;
sposób przechowywania w pamięci/na karcie SD.

Konfiguracji nie należy kopiować mechanicznie między platformami. Test odbiorczy musi używać dokładnie tego firmware, parametrów i GCS, które trafią do operacji.

Fixed wing VTOL i inne platformy#

Multirotor może wyhamować i wykonać ruch prawie w dowolnym kierunku, o ile ma zapas ciągu. Fixed-wing musi utrzymać prędkość, ma minimalny promień zakrętu i zależność toru od wiatru. Fence dla samolotu wymaga większego look-ahead i bufora.

Przy koordynowanym zakręcie przybliżony promień:

R = V_air² / (g · tan(phi))

Tor względem ziemi zależy jednak od wektora wiatru. Dla zakrętu pod wiatr i z wiatrem geometria jest różna. Limity bank angle mogą zostać obniżone przez oblodzenie, awarię, konfigurację ładunku albo procedurę bezpieczeństwa. Fence powinien używać najgorszego kwalifikowanego przypadku.

VTOL w trybie samolotowym ma ograniczenia fixed-wing, a po transition — multirotora. Sama transition zajmuje przestrzeń, czas i energię. Nie należy inicjować jej tuż przy granicy bez sprawdzenia pełnej trajektorii.

UGV wymaga uwzględnienia footprintu i kinematyki skrętu, ale nie limitu wysokości lotu. USV ma dryf od prądu i fal oraz długą drogę hamowania. Ten sam format polygon fence może być współdzielony, lecz model dynamiki i akcja awaryjna nie są przenośne.

Logowanie i obserwowalność#

Minimalny rekord diagnostyczny geofence powinien zawierać:

aktywny fence_set_id, revision i hash;
tryb inclusion/exclusion oraz frame wysokości;
stan enabled/armed/healthy;
estymowaną pozycję, covariance i identyfikator źródła;
najbliższą granicę i signed clearance;
prędkość zamykania oraz time-to-boundary;
dynamiczny margines i przewidywany breach;
powód zmiany stanu;
komendę wejściową i komendę po ograniczeniu;
akcję failsafe oraz jej wynik;
resety estymatora, zmianę origin i home;
zdarzenia upload/download/clear z identyfikatorem nadawcy.

W telemetrii operator potrzebuje informacji syntetycznej: fence aktywny, stan poprawny, dystans do najbliższej granicy, rodzaj zagrożenia i planowana reakcja. Migająca ikona bez przyczyny nie wystarcza.

Przy analizie naruszenia należy na jednej osi czasu zestawić pozycję, covariance, prędkość, setpoint, aktywną krawędź, akcję oraz nasycenie sterowania. Pozwala to rozróżnić błędną mapę, późną decyzję, zbyt mały margines i brak możliwości dynamicznej.

SITL HIL i fault injection#

Test nominalny polegający na powolnym dolecie do okręgu jest tylko początkiem. Macierz testów powinna obejmować:

Geometria#

punkty wewnątrz, na granicy i poza nią;
każdy wierzchołek i krawędź poziomą/pionową;
wielokąt wklęsły;
duplikaty, krawędź zerowej długości i samoprzecięcie;
rozłączne i nakładające się inclusion zones;
exclusion dotykające inclusion;
południk 180° i obszar przy granicy projekcji;
minimalny korytarz po zastosowaniu bufora;
floor i ceiling w każdym obsługiwanym frame.

Dynamika#

maksymalna prędkość wprost na granicę;
lot styczny i narożnik;
wiatr odpychający i spychający;
maksymalna masa oraz ograniczony thrust;
fixed-wing przy minimalnym i maksymalnym promieniu zakrętu;
transition VTOL blisko granicy;
opóźnione setpointy companion computera.

Estymacja#

GNSS dropout;
rosnąca covariance bez utraty flagi fix;
skok pozycji i reset EKF;
stale GNSS z aktualnym timestampem transportowym;
przełączenie GNSS/VIO;
błędna wysokość geoidy;
dryf barometru przez floor/ceiling;
rozbieżność dwóch odbiorników.

Dane i protokół#

utrata łącza w połowie uploadu;
duplikacja i zmiana kolejności pakietów;
niewłaściwy mission type;
przekroczenie limitu wierzchołków;
NaN, infinity i współrzędne poza zakresem;
rollback revision;
wygaśnięcie strefy w trakcie lotu;
restart autopilota i GCS;
odczyt zwrotny różny od wysłanego zestawu.

SITL pozwala automatyzować geometrię i maszyny stanów. HIL ujawnia scheduling, opóźnienia i zachowanie rzeczywistych interfejsów. Próby uwięzione z odłączonym napędem lub na bezpiecznym stanowisku potwierdzają reakcje przed swobodnym lotem. Każdy test powinien sprawdzać nie tylko końcowy mode, ale także maksymalne przekroczenie, czas reakcji i kompletność logu.

Kryteria odbioru#

Przykładowe, mierzalne kryteria trzeba dostosować do platformy:

Obszar	Kryterium
aktywacja	niekompletny upload nigdy nie zastępuje poprzedniego fence
geometria	zestawy nieważne są odrzucane z identyfikowalnym powodem
integralność	hash po read-back odpowiada zatwierdzonej reprezentacji
pozycja	fence nie przechodzi do stanu clear przy invalid position
dynamika	maksymalne naruszenie pozostaje poniżej limitu dla kwalifikowanych prędkości i wiatru
pion	wszystkie konwersje wysokości mają jawny frame i test round-trip
restart	aktywna wersja i akcja po restarcie są zgodne z wymaganiem
telemetria	operator widzi stan, najbliższą granicę i powód reakcji
log	można odtworzyć konfigurację, stan estymatora i decyzję
wersje	zestaw testów jest przypięty do build ID firmware i GCS

Wymóg „zero przekroczenia” trzeba odnieść do konkretnej granicy operacyjnej. Rozsądna architektura tworzy wewnętrzną granicę sterowania z buforem przed granicą twardą. Dopuszczalne odchylenie od granicy sterowania nie może naruszyć zewnętrznej granicy bezpieczeństwa.

Typowe błędy#

Traktowanie fence jako źródła prawa#

Mapa w aplikacji może być niepełna lub nieaktualna. Pokładowa funkcja nie zastępuje przygotowania operacji i aktualnego źródła informacji lotniczej.

Sprawdzanie tylko waypointów#

Odcinek, spline, zakręt, loiter lub Return mogą wyjść poza strefę mimo poprawnych punktów końcowych.

Brak marginesu#

Test punktu referencyjnego ignoruje footprint, niepewność mapy, błąd pozycji, tracking i drogę hamowania.

Jeden stały margines#

Ta sama wartość nie odpowiada wolnemu multirotorowi i szybkiemu fixed-wing. Bufor powinien wynikać z dynamiki i jakości stanu.

Nieznane odniesienie wysokości#

AGL, home-relative, AMSL i wysokość elipsoidalna nie są zamienne. Błąd może wynosić dziesiątki metrów.

Częściowa aktualizacja#

Aktywowanie prefiksu po zerwanym transferze zmienia geometrię w sposób trudny do zauważenia. Potrzebny jest staging i atomic commit.

Return po prostej#

Najkrótsza linia do home może przecinać exclusion albo być dynamicznie niewykonalna. Trasa powrotu musi być walidowana jak osobna misja.

Ignorowanie pozycji invalid#

Brak wiarygodnego położenia nie oznacza, że statek znajduje się wewnątrz. Jest osobnym stanem failsafe.

Ciche uproszczenie danych#

Redukcja wierzchołków może powiększyć inclusion albo zmniejszyć exclusion. Konwersja musi być konserwatywna i raportowana.

Testowanie tylko na mapie#

Symulacja geometryczna nie ujawnia opóźnienia, wiatru, nasycenia regulatora i resetów estymatora. Potrzebne są SITL, HIL oraz próby ograniczone.

Geofence jest skuteczny dopiero wtedy, gdy geometryczna granica staje się wersjonowanym, monitorowanym i przetestowanym kontraktem między źródłem danych, plannerem, estymatorem, autopilotem i procedurą operatora.

Powiązane tematy#

Przypisy#

PX4, „Geofence”, bieżąca dokumentacja projektu — typy granic i konfiguracja.
PX4, „Return Mode” — planowanie powrotu uwzględniające fence, limity reprezentacji i zastrzeżenia dotyczące błędu śledzenia.
PX4, „Safety Configuration and Failsafes” — kontekst konfiguracji reakcji bezpieczeństwa.
ArduPilot, „Polygon and Circular Inclusion/Exclusion Fences” — geometria, kombinowanie stref, limity i zależność od pozycji.
ArduPilot, „Copter parameter reference” — parametry FENCE_*; wartości należy sprawdzać dla konkretnego wydania.
MAVLink, „Mission Protocol” — transakcyjny transfer mission, fence i rally oraz typy zestawów.
EASA, „Easy Access Rules for Unmanned Aircraft Systems”, rewizja z czerwca 2026 r. — strefy geograficzne UAS i kontekst regulacyjny.

Źródła z centralnego rejestru

PX4 User Guide: Geofence [dokumentacja projektu]
PX4 User Guide: Return Mode — geofence-aware path planning [dokumentacja projektu]
PX4 User Guide: Safety Configuration and Failsafes [dokumentacja projektu]
ArduPilot: Polygon and Circular Inclusion/Exclusion Fences [dokumentacja projektu]
ArduPilot Copter parameter reference: FENCE parameters [dokumentacja projektu — wartości sprawdzać dla używanej wersji firmware]
MAVLink: Mission Protocol [specyfikacja protokołu]
EASA: Easy Access Rules for Unmanned Aircraft Systems — revision June 2026 [przepisy i materiały instytucji lotniczej]