Omijanie przeszkód UAV

Omijanie przeszkód UAV nie zaczyna się od wyboru algorytmu A* ani kończy na wykryciu najbliższego punktu. Jest warstwowym systemem: sensory opisują tylko część przestrzeni, estimator przypisuje pomiar do czasu i układu, mapper rozróżnia free, occupied oraz unknown, planner proponuje wykonalną trajektorię, a flight controller egzekwuje ograniczenia nawet po utracie companion computera. Błąd dowolnej warstwy może dać trajektorię matematycznie poprawną w mapie, która nie odpowiada światu.

Collision prevention i obstacle avoidance są różnymi funkcjami. Pierwsza ogranicza komendę lub zatrzymuje platformę przed bliską przeszkodą. Druga wyszukuje alternatywną drogę do celu. Trzecia klasa, detect and avoid wobec innych statków powietrznych, używa innych sensorów, horyzontów czasu oraz kryteriów separacji i nie jest przedmiotem tego artykułu.

Spis treści#

Warstwy systemu
Collision prevention a path planning
Obwiednia percepcji
Sensory
Timestamp i transformacje
Od punktu do mapy lokalnej
Free occupied i unknown
Footprint UAV i inflacja
Droga zatrzymania
Latency i częstotliwość
Dynamiczne przeszkody
Collision prevention w flight controllerze
Local planner
Global planner
BendyRuler i Dijkstra
ESDF i optymalizacja trajektorii
Wykonalność dynamiczna
Kontrakt setpointów
MAVLink OBSTACLE_DISTANCE
Status integracji PX4
Praca bez GNSS
Fixed-wing i VTOL
Fail-safe i graceful degradation
Logowanie i metryki
SITL HIL i fault injection
Kryteria odbioru
Typowe błędy
Powiązane tematy
Przypisy

Warstwy systemu#

Referencyjny przepływ:

lidar/radar/depth/stereo → timestamp + calibration + filtering
                         → local occupancy/ESDF + dynamic tracks
mission/global map       → global route
local map + route        → local trajectory
trajectory + constraints → setpoints
setpoints + sectors      → FC collision prevention
FC state/failsafe        → actuators

Każda strzałka ma deadline, frame i stan ważności. Planner nie może otrzymać chmury bez informacji, czy jest w camera, body, odom czy map. Flight controller nie może interpretować braku pakietu jako „brak przeszkód”.

Warstwa końcowa przy flight controllerze powinna być prosta i niezależna od pełnego mappera. Nawet gdy globalny planner się restartuje, FC może zatrzymać ruch w kierunku świeżo wykrytej przeszkody albo wejść do ustalonego trybu po utracie setpointów.

Collision prevention a path planning#

Funkcja	Wejście	Wynik	Horyzont
collision prevention	odległości/sektory + velocity	ograniczona komenda lub stop	krótki
reactive avoidance	local obstacles + cel	zmieniony kierunek	krótki/średni
local trajectory planner	mapa 3D + stan + route	dynamicznie wykonalna trajektoria	kilka sekund
global planner	mapa/fence + start/cel	topologiczna trasa	długa misja
DAA air traffic	tracki innych statków	alert/manewr separacji	odległy konflikt

Collision prevention nie obiecuje dotarcia do celu. Może zatrzymać UAV w ślepym zaułku. Local planner nie gwarantuje globalnego obejścia dużej bariery bez route. Global planner może ignorować nową przeszkodę i wymagać lokalnego replanu.

Projekt powinien jawnie określić, która warstwa ma ostatnie słowo. Safety constraints w FC nie mogą zostać nadpisane przez companion setpoint o wyższym priorytecie bez kontrolowanej procedury.

Obwiednia percepcji#

Sensor ma pole widzenia, zasięg, minimalną odległość, rozdzielczość i martwe sektory. Obwiednia powinna być wyrażona jako funkcja:

P_detect(object | range, angle, size, material, light/weather, motion)

Nie wystarcza „lidar 360°”. Obracający się lidar może mieć ograniczony pionowy FOV, zasłonięcie przez ramiona, niższą gęstość przy szybkim yaw i strefę martwą. Kamera depth może nie widzieć pod słońce. Radar może wykryć obiekt, lecz z dużą niepewnością kątową.

Coverage map przechowuje dla każdego sektora:

obserwowany/nieobserwowany;
timestamp ostatniej obserwacji;
min/max range;
resolution/footprint;
confidence;
expected occlusion;
sensor source.

PX4 Collision Prevention utrzymuje reprezentację sektorową i domyślnie ogranicza ruch w kierunkach bez danych; opcja pozwalająca jechać/lecieć w no-data zmienia założenie bezpieczeństwa i wymaga osobnej kwalifikacji.

Sensory#

Lidar 2D/3D#

Zapewnia bezpośredni range, lecz cienkie przewody, szkło, czerń, deszcz i wzór skanowania są problemami. Skan wymaga deskew. 2D lidar widzi tylko płaszczyznę, która przy pitch może przejść nad lub pod przeszkodą.

Stereo i depth camera#

Tworzy gęstszą informację w FOV. Stereo traci dokładność głębokości z odległością i wymaga tekstury; active depth ma ograniczenia słońca, refleksów i zasięgu. Każdy piksel depth potrzebuje statusu invalid/unknown.

Radar#

Może działać w warunkach optycznie trudnych i dostarczać radial velocity. Rozdzielczość kątowa, sidelobes i clutter wymagają trackingu. Nie należy przekształcać szerokiej detekcji w punkt o zerowej covariance.

Sonar#

Przydatny na małym dystansie, ma szeroką wiązkę i zależność od przepływu powietrza, temperatury oraz materiału. Jeden wynik nie opisuje kierunku w obrębie wiązki.

Monocular vision#

Może wykryć klasę obiektu lub time-to-collision, ale metryczna głębokość bez geometrii/VIO jest słabsza. Detektor 2D nie daje bezpośrednio clearance.

Fuzja sensorów powinna zachować pochodzenie i covariance. Minimum z wielu sensorów jest konserwatywne wobec przeszkody, lecz podatne na pojedynczy fałszywy bliski return. Głosowanie może zignorować cienki obiekt widziany tylko przez najlepszy sensor.

Timestamp i transformacje#

Każdy pomiar trzeba przeliczyć do mapy w czasie akwizycji:

p_odom(t_sample) = T_odom_body(t_sample) · T_body_sensor · p_sensor

Użycie bieżącej pozy dla starego pomiaru przesuwa przeszkodę o około vΔt i obraca o ωΔt. Dla skanu lidarowego każdy punkt ma inny czas.

Transformacja zawiera lever arm. Podczas yaw sensor oddalony od środka ma prędkość omega × r. Błędna ekstrynsyka tworzy przeszkody poruszające się razem z manewrem.

Po loop closure globalny map może skoczyć. Local safety map powinna działać w ciągłym odom. Jeżeli planner globalny używa map, transformacja map→odom musi aktualizować route bez wywołania fizycznego skoku setpointu.

Od punktu do mapy lokalnej#

Point cloud nie rozróżnia przestrzeni wolnej od nieznanej. Sensor model raycasts od origin do returnu:

origin → cells before hit: evidence free
hit cell: evidence occupied
beyond hit: unknown/occluded

Occupancy aktualizuje log-odds z ograniczeniem min/max confidence. Rolling map usuwa stare regiony i utrzymuje bounded memory. Local map powinna zawierać map age oraz bounds.

Alternatywą jest TSDF/ESDF. TSDF integruje signed distance w pobliżu powierzchni, ESDF dostarcza odległość do przeszkody dla trajectory optimization. Voxblox jest przykładem inkrementalnego 3D ESDF zaprojektowanego dla on-board MAV planning.

Wybór resolution jest kompromisem. Voxel większy od przewodu może go usunąć. Voxel bardzo mały zwiększa pamięć i czas aktualizacji, co może dać bardziej opóźnioną, a więc mniej bezpieczną mapę.

Free occupied i unknown#

unknown nie oznacza free. Przyczyny unknown:

brak FOV;
occlusion za przeszkodą;
brak returnu;
nieważny depth;
zbyt stara obserwacja;
region poza mapą;
usunięty blok rolling map.

Polityki:

unknown=occupied — konserwatywna, może blokować eksplorację;
unknown=free — ryzykowna, wymaga ograniczenia prędkości i stopping within observed space;
frontier policy — planner może wejść w unknown tylko trajektorią, której odcinek zatrzymania pozostaje w aktualnie obserwowanym free.

Trzecia jest użyteczna w eksploracji. Kluczowy invariant:

distance_to_end_of_verified_free_along_trajectory
> stopping_distance + localization/map margin

No-return nie może być automatycznie free do max range, jeśli sensor nie gwarantuje wykrycia docelowego materiału.

Footprint UAV i inflacja#

Planner zwykle planuje punkt reprezentujący body, ale UAV ma objętość. Configuration space powiększa przeszkody o footprint platformy.

Inflacja obejmuje:

airframe radius/shape
+ localization covariance
+ map/sensor uncertainty
+ tracking error
+ latency motion
+ downwash/operational clearance
+ payload protrusions

Kula jest konserwatywna, ale może blokować wąskie przejścia. Oriented box/capsule lepiej wykorzystuje geometrię, lecz wymaga planowania attitude. Multirotor tilt zwiększa boczny obrys i wysokość łopat.

Footprint jest konfiguracją egzemplarza. Zmieniony payload, podwozie lub antena wymaga aktualizacji. Nie wolno przechowywać promienia tylko w kodzie planera bez wersjonowania.

Droga zatrzymania#

Podstawowe przybliżenie:

d_stop = v · t_total + v²/(2 a_brake) + d_jerk + margin

t_total obejmuje age sensora, przetwarzanie, komunikację, planowanie, setpoint i reakcję napędu. a_brake jest osiągalnym opóźnieniem w bieżącym kierunku, masie, tilt i stanie baterii. d_jerk uwzględnia narastanie przyspieszenia.

PX4 Collision Prevention uwzględnia jerk, przyspieszenie i zadeklarowane opóźnienie przy ograniczaniu prędkości. To właściwy kierunek: max speed wynika z range oraz dynamiki, a nie z arbitralnej stałej.

Dla ruchu 3D oblicza się projekcję prędkości na kierunek przeszkody. UAV może odlecieć równolegle bez zmniejszania clearance, ale obrót/tracking error nadal wymaga marginesu.

Test hamowania musi mierzyć worst-case na pełnej masie, słabej baterii, wietrze oraz z realnym filtrem. Parametr z nominalnego modelu nie jest dowodem.

Latency i częstotliwość#

Rate bez age jest mylący. Stream 30 Hz może publikować dane opóźnione o 300 ms. Mierzy się:

sensor acquisition time;
transform/deskew completion;
map update time;
planner input/output;
FC receive/use time;
actuator response.

p50, p95, p99 i max są ważniejsze niż średnia. Loop closure, allocator memory, thermal throttling i zapis logu mogą tworzyć ogon rozkładu.

Queue latest-only jest często właściwa dla safety map: stara chmura nie odzyska aktualności. Jednocześnie raw logger może zachować wszystkie dane w osobnym torze.

Stale threshold powinien wynikać z prędkości i range. Timeout 500 ms może być akceptowalny w zawisie, a niemożliwy przy 15 m/s.

Dynamiczne przeszkody#

Statyczna occupancy zostawia ghost po poruszającym się człowieku. Dynamic layer śledzi obiekty:

state_object = [position, velocity, covariance, class, age]

Predykcja zajętości w czasie pozwala ocenić trajectory, nie tylko bieżący punkt. Time-to-collision:

r = p_obstacle - p_vehicle
v_rel = v_obstacle - v_vehicle
t_cpa = - (r · v_rel) / ||v_rel||²

Najbliższy punkt podejścia jest ważny, gdy t_cpa>0. Covariance rośnie z horyzontem.

Static/dynamic classification może być błędna. System powinien zachować przeszkodę w safety layer nawet bez stabilnego track ID. Temporal decay usuwa ghosts, ale zbyt szybki decay usuwa obiekt po chwilowej occlusion.

Woda, gałęzie i trawa dają pozorny ruch. Robust tracking oraz sensor diversity ograniczają false tracks.

Collision prevention w flight controllerze#

FC ma szybki state i kontroluje actuators, dlatego końcowe ograniczenie velocity/acceleration powinno być blisko niego. Może działać na sektorach odległości, nie pełnej mapie.

Logika:

desired acceleration/velocity
→ project toward obstacle directions
→ compute allowed speed from distance, delay and braking
→ constrain inward component
→ retain tangential/away component where safe

PX4 opisuje 72 sektory, fresh observations/no-data i ograniczanie acceleration setpoint. To collision prevention, nie globalny route planner.

FC powinien odrzucać:

invalid increment/frame;
stale timestamps;
distance poniżej min lub powyżej semantyki;
niespójne min/max;
skok całej mapy bez resetu;
brak heartbeat companion, jeśli tryb go wymaga.

Override operatora, jeśli dopuszczony, musi być jawny, logowany i mieć tryb. Ukryta możliwość „przepchnięcia stickiem” zmienia wymaganie bezpieczeństwa.

Local planner#

Local planner otrzymuje bieżący stan, local map i fragment global route. Generuje trajektorię w ograniczonym horyzoncie.

Rodziny:

sampling-based velocity/trajectory candidates;
vector field/reactive direction search;
kinodynamic A*/RRT;
optimization na ESDF;
model predictive control z obstacle constraints.

Funkcja kosztu może zawierać:

J = w_goal J_goal
  + w_clear J_clearance
  + w_smooth J_accel_jerk
  + w_route J_deviation
  + w_unknown J_unknown
  + w_dynamic J_collision_probability

Same wagi nie gwarantują safety. Minimalny clearance powinien być hard constraint lub niezależnie egzekwowany. Jeśli optimizer nie zbiega w deadline, wynik nie może być użyty po terminie.

Local minima występują w U-shape, drzwiach i clutter. Local planner potrzebuje recovery lub globalnego reroute.

Global planner#

Global planner szuka drogi w większej mapie i wokół fences. A*, Dijkstra i graf widoczności operują na dyskretnym grafie/siatce; sampling planners w przestrzeni ciągłej. Wynik jest route, niekoniecznie dynamicznie wykonalną trajectory.

Global map może być nieaktualna. Local planner musi mieć prawo odrzucić route. Po wykryciu trwałej blokady wysyła request replan z aktualną map revision i start state.

Global route nie powinien przechodzić przez unknown bez polityki. Koszt unknown może być wysoki, lecz eksploracja nadal możliwa. Route musi uwzględniać geofence, wysokości, terrain i energy-to-return.

Po loop closure map→odom zmienia route w lokalnym układzie. Aktywna trajectory jest unieważniana lub przeliczana i ponownie sprawdzana.

BendyRuler i Dijkstra#

ArduPilot BendyRuler sonduje kierunki wokół pojazdu, szukając przestrzeni wystarczająco otwartej i postępu do celu. Jest plannerem lokalnym; nie gwarantuje najkrótszej drogi ani wyjścia z każdego układu przeszkód.

Dokumentacja ArduPilot opisuje połączenie Dijkstra z BendyRuler: Dijkstra planuje wokół fences/global geometry, a BendyRuler reaguje na proximity obstacles. To ilustruje właściwy podział global/local.

Parametry look-ahead muszą odpowiadać zasięgowi sensora i stopping distance. Zbyt krótki horyzont reaguje późno; zbyt długi może odrzucać wąskie przejścia i opierać się na niedokładnych danych.

Simple avoidance w trybach manualnych może dodać korektę/stop, ale zachowanie i możliwość pokonania korekty przez operatora zależą od firmware/trybu. Nie wolno przenosić założeń między trybami AUTO, GUIDED, LOITER i ALTHOLD bez sprawdzenia dokumentacji wersji.

ESDF i optymalizacja trajektorii#

ESDF daje signed/euclidean distance d(p) do najbliższej przeszkody i gradient. Koszt clearance może rosnąć, gdy d spada poniżej progu.

Zalety:

szybkie zapytanie distance;
gradient dla optimizer;
naturalna inflacja;
3D trajectory w clutter.

Ryzyka:

stale ESDF;
błąd na unknown boundary;
thin object znikający w voxelu;
update latency po dynamic obstacle;
local map truncation.

Planner powinien otrzymać map timestamp i revision. Trajectory ma ważność tylko względem konkretnej rewizji. Przed wykonaniem kolejne punkty są ponownie collision-checkowane w najnowszej mapie.

Wykonalność dynamiczna#

Geometrycznie wolny spline może wymagać niemożliwego acceleration lub tilt. Constraints:

velocity w osiach;
acceleration/thrust magnitude;
jerk;
yaw rate;
tilt i thrust margin;
fixed-wing airspeed/load factor/climb;
VTOL transition state;
tracking error.

Trajectory collision checking powinno używać swept volume, nie tylko waypointów. Między dwoma wolnymi punktami odcinek może przecinać przeszkodę.

Tracking controller nie odtwarza trajectory idealnie. Clearance margin obejmuje measured tracking error distribution. Jeśli wiatr/saturacja zwiększa błąd, planner obniża speed lub przechodzi do failsafe.

Kontrakt setpointów#

Interfejs planner→FC określa:

timestamp and valid_until
frame_id
position/velocity/acceleration/yaw fields and NaN semantics
trajectory horizon and sample spacing
map revision / reset counter
planner health and reason
constraints assumed
sequence number

Brak setpointu, stary setpoint i jawny HOLD to różne stany. Heartbeat bez świeżej trajectory nie oznacza sprawnego planera.

FC powinien mieć timeout i ustaloną reakcję. Ostatni velocity setpoint nie może być utrzymywany bezterminowo po utracie łącza.

Ramę wybiera się pod kątem ciągłości. Local setpoints w odom nie skaczą po loop closure; global mission w map wymaga adaptera.

MAVLink OBSTACLE DISTANCE#

OBSTACLE_DISTANCE przenosi tablicę do 72 odległości. Kluczowe pola:

time_usec;
sensor_type;
distances[72] w cm;
increment lub increment_f;
angle_offset;
min_distance, max_distance;
frame.

Specyfikacja rozróżnia:

0 — przeszkoda praktycznie dotyka sensora;
max_distance+1 — brak przeszkody w zasięgu;
UINT16_MAX — unknown/not used.

Pomylenie unknown z no-obstacle jest krytyczne. frame określa, czy kąty są north-aligned czy body FRD. Dla body-mounted sensorów używa się właściwej ramy; obrót UAV nie może obracać statycznej mapy dwa razy.

Sektorowa wiadomość traci wysokość przeszkody. Nadaje się do poziomej collision prevention, nie pełnej 3D mapy. FOV overlap i binning powinny konserwatywnie zachować najbliższą przeszkodę.

DISTANCE_SENSOR niesie pojedynczy pomiar, orientation/quaternion, FOV, covariance i signal quality. Sterownik musi poprawnie ustawić te pola, aby agregator wiedział, które sektory są obserwowane.

Status integracji PX4#

Aktualna dokumentacja PX4 main opisuje Collision Prevention jako wspieraną funkcję sektorową w odpowiednich trybach multicoptera/VTOL MC. Jednocześnie dawny Path Planning Interface dla mission obstacle avoidance został usunięty w PX4 v1.15 i dokumentacja ostrzega, że nie jest wspierany ani utrzymywany.

To ważna lekcja aktualności: artykuły i integracje oparte na dokumentacji v1.14 mogą opisywać interfejs obecny historycznie, ale niewłaściwy dla nowych wersji. Nowa architektura companion planning powinna korzystać z aktualnych, wspieranych mechanizmów, np. zewnętrznych trybów/interfejsu ROS 2 odpowiedniego dla wersji, i mieć własny kontrakt failsafe.

Nie należy aktywować starego parametru/interfejsu tylko dlatego, że kod nadal istnieje. Status utrzymania, test cards i wersja firmware są częścią kwalifikacji.

Praca bez GNSS#

Obstacle avoidance może działać w local odom z VIO/LIO/SLAM. Wymaga:

valid local position/velocity;
ciągłości ramy;
bounded drift w horyzoncie planera;
poprawnej gravity/attitude;
obsługi relocalization reset;
mapy lokalnej współdzielącej trajectory frame.

Jeśli local position traci ważność, sama chmura w body może nadal pozwolić na emergency stop, ale nie na bezpieczne obejście do celu. Tryb powinien zejść z planning do collision prevention/hold/land zgodnie ze scenariuszem.

Yaw drift obraca global route względem local obstacles. Po korekcie yaw nie można nagle obrócić aktywnego setpointu bez sprawdzenia.

Fixed-wing i VTOL#

Fixed-wing nie może zawisnąć ani cofnąć się. Horyzont sensora i planera musi odpowiadać promieniowi zakrętu, climb rate i airspeed. Local reactive turn może wprowadzić stall albo bank w stronę innej przeszkody.

Minimalna geometria zakrętu przy uproszczeniu coordinated turn:

R_turn = v² / (g tan(phi))

Wind zmienia ground track i zasięg potrzebny do obejścia. Planner musi działać w przestrzeni stanów, nie tylko przesunąć waypoint.

VTOL ma różne constraints w MC, transition i FW. Trajectory bez oznaczenia vehicle mode może być niewykonalna po transition. Collision sectors mogą być zasłonięte inaczej przez obrót płatowca.

Artykuł skupia się głównie na małych multirotorach, ponieważ tam funkcje sektorowego stop są najprostsze. Przeniesienie do fixed-wing wymaga osobnej kwalifikacji.

Fail-safe i graceful degradation#

Maszyna stanów:

FULL_AUTONOMY
LOCAL_AVOIDANCE_ONLY
COLLISION_PREVENTION_ONLY
HOLD_OR_BRAKE
CONTROLLED_ESCAPE
LAND_OR_RTL
MANUAL

Przejścia zależą od tego, co utracono:

global map/route — local hold/replan może działać;
local planner — FC collision prevention + hold;
obstacle sensor częściowo — blokada no-data directions/reduced speed;
local position — body-frame brake lub scenariuszowy land;
companion — timeout FC;
FC obstacle map — nie kontynuować autonomous motion.

Hold nie zawsze jest bezpieczny: fixed-wing, ruchoma przeszkoda, silny wiatr lub tunel. Land nie zawsze jest bezpieczny nad wodą/ruchem. Escape climb nie jest bezpieczny pod sufitem. Reakcja wynika z environment class i dostępnych sensorów.

Recovery wymaga kilku kolejnych świeżych, spójnych cykli oraz replanu od bieżącego stanu. Nie wraca się do starej trajectory po pojedynczym pakiecie.

Logowanie i metryki#

Log powinien łączyć:

raw/filtered sensor data i quality;
coverage/no-data map z age;
local occupancy/ESDF revisions;
state/velocity/covariance;
candidate trajectories i costs;
wybraną trajectory oraz rejection reasons;
setpoint przed i po collision prevention;
constraints i saturation;
heartbeat/timeouts/state transitions;
minimum predicted i actual clearance;
CPU/memory/temperature.

Metryki percepcji:

probability of detection per object/range/angle;
false positive rate;
range/angle error;
coverage i stale fraction;
end-to-end age.

Metryki planera:

success rate;
plan time p50/p95/p99/max;
minimum clearance;
path length/time/energy;
jerk/acceleration violations;
replan count;
deadlock rate.

Metryki systemu:

collision/near-miss rate;
stopping error;
intervention/failsafe rate;
unknown-space violations;
tracking error;
recovery time.

Średnia minimalna odległość nie wystarcza; raportuje się najgorszy przypadek i percentyle w klasach scen.

SITL HIL i fault injection#

Biblioteka scen powinna zawierać:

pojedynczą ścianę;
cienki słup/przewód;
korytarz i drzwi;
U-shape/dead end;
przeszkodę poza płaszczyzną 2D lidaru;
moving crossing object;
nagle pojawiający się obiekt;
szkło/czerń/no-return;
partial sensor coverage;
indoor GNSS denied;
loop closure/reset;
fixed-wing infeasible turn.

Fault injection:

freeze obstacle array z rosnącym timestampem i bez;
delay/jitter/drop/reorder;
zamiana frame lub angle sign;
UINT16_MAX↔max+1;
fałszywy bliski punkt;
usunięcie cienkiego obiektu przez voxel filter;
stale ESDF;
planner overrun/OOM/restart;
local position jump;
utrata jednego z redundantnych sensorów;
actuator/braking degradation.

SITL sprawdza logikę stanów i map. HIL dodaje realne timingi oraz interfejs FC-companion. Próby fizyczne zaczynają się z uwięzią/małą prędkością i miękkimi przeszkodami, ale finalna kwalifikacja musi używać reprezentatywnych materiałów oraz dynamiki.

Stopping test mierzy od chwili fizycznej obserwacji, nie od chwili publikacji detekcji. High-speed test jest dopuszczany dopiero po wykazaniu range i deadline margin.

Kryteria odbioru#

Coverage oraz no-data sectors są znane dla całej obwiedni lotu.
Unknown jest odróżnione od no-obstacle w każdym interfejsie.
Wszystkie pomiary mają acquisition timestamp i poprawny frame.
Deskew/lever arm są uwzględnione przy ruchu.
Thin obstacles spełniają zadaną probability of detection.
Footprint obejmuje payload, tilt i tracking uncertainty.
Stopping distance używa zmierzonego worst-case delay, jerk i brake.
Max speed jest automatycznie ograniczony przez observed free range.
Local map ma bounded memory, age i revision.
Dynamic obstacles mają prediction/covariance albo konserwatywną warstwę.
Hard clearance constraint nie zależy wyłącznie od soft cost.
Trajectory jest sprawdzana jako swept volume i dynamicznie wykonalna.
FC timeout zatrzymuje użycie starego setpointu.
Loop closure/reset nie powoduje skoku aktywnej trajectory.
Planner failure przechodzi do zdefiniowanej bezpiecznej warstwy.
Recovery wymaga stabilnych świeżych danych i replanu.
Status używanych interfejsów jest zgodny z wersją firmware.
Fault injection pokrywa stale, no-data, frame error i companion loss.
Log pozwala odtworzyć sensor→map→plan→FC decision.
Testy obejmują reprezentatywne materiały, światło, pogodę i prędkość.

Typowe błędy#

Nazwanie prostego stop „pełnym obstacle avoidance”.
Traktowanie unknown jako free.
Użycie timestampu odbioru zamiast akwizycji.
Mapowanie skanu jedną pozą bez deskew.
Zamiana north-aligned i body-frame sektorów.
Wypełnienie brakujących sektorów maksymalnym zasięgiem.
Voxel większy od cienkiej przeszkody.
Inflacja tylko o promień kadłuba.
Droga hamowania bez latency i jerk.
Parametr hamowania z modelu zamiast z testu.
Planner optymalizujący miękki koszt bez hard clearance.
Collision checking tylko waypointów, nie odcinków/swept volume.
Stara ESDF bez revision i valid_until.
Ostatni setpoint utrzymywany po utracie companion.
Global route uznany za trajectory wykonalną.
Brak recovery z U-shape/dead end.
Hold jako uniwersalny failsafe.
Przeniesienie logiki multirotora na fixed-wing.
Implementacja na wycofanym PX4 Path Planning Interface.
Test tylko w Gazebo z idealnym lidarem.

Powiązane tematy#

Lidar w UAV — returny, zasięg, FOV i błędy sensora.
Radar pokładowy UAV — detekcja i velocity w warunkach optycznie trudnych.
SLAM dla UAV — occupancy, ESDF, map/odom i loop closure.
Terrain following UAV — grunt a przeszkoda i look-ahead.
Mapowanie lidarowe UAV — deskew i geometria chmury.
Visual odometry i VIO — local state bez GNSS.
Failsafe jako maszyna stanów — degradacja i recovery.
MAVLink — architektura protokołu — transport danych companion–FC.
Bilans cieplny elektroniki UAV — throttling i deadline komputera.

Przypisy#

Bibliografia jest generowana z centralnego rejestru. Aktualne zachowanie sektorowego Collision Prevention, no-data policy, opóźnienie i uwzględnienie jerk/braking oparto na dokumentacji PX4 main. Status dawnego Path Planning Interface — usuniętego w PX4 v1.15 i nieutrzymywanego — pochodzi z bieżącej dokumentacji projektu; materiały v1.14 mają wartość historyczną, nie są zaleceniem integracyjnym. Podział globalnego Dijkstra i lokalnego BendyRuler oraz simple avoidance oparto na dokumentacji ArduPilot. Semantykę OBSTACLE_DISTANCE, DISTANCE_SENSOR, UINT16_MAX, max_distance+1, ramek i FOV oparto na specyfikacji MAVLink. Occupancy/unknown porównano z OctoMap, a ESDF z voxblox. Wszystkie limity prędkości, opóźnienia i zasięgu wymagają kwalifikacji konkretnej platformy.

Źródła z centralnego rejestru

PX4: Collision Prevention [dokumentacja projektu]
PX4: Path Planning Interface — removed and no longer supported [dokumentacja statusu historycznego interfejsu]
ArduPilot: Object Avoidance with BendyRuler [dokumentacja projektu]
ArduPilot: Object Avoidance using Dijkstra with BendyRuler [dokumentacja projektu]
ArduPilot: Simple Object Avoidance [dokumentacja projektu]
MAVLink Common Message Set: OBSTACLE_DISTANCE and DISTANCE_SENSOR [specyfikacja protokołu]
OctoMap: probabilistic 3D occupancy mapping library [dokumentacja projektu]
Oleynikova et al.: Voxblox — Incremental 3D Euclidean Signed Distance Fields for On-Board MAV Planning [publikacja naukowa]
ETH Zurich ASL: voxblox [repozytorium open source]
Livox Mid-360 User Manual [dokumentacja producenta]