Commissioning przekształca zmontowany prototyp w konfigurację, o której wiadomo, że odpowiada dokumentacji i spełnia minimalne kryteria lotu. Nie jest jednym „pierwszym startem”. To sekwencja bramek: inspekcja bez energii, kontrolowane zasilenie, identyfikacja sprzętu, konfiguracja i testy bez śmigieł, weryfikacja failsafe, próby naziemne, pierwszy zawis oraz stopniowe rozszerzanie obwiedni. Każda bramka ma dowód i warunek przerwania.

Spis treści#

Commissioning a rozwój#

Commissioning odpowiada na pytanie: czy konkretny egzemplarz, w konkretnej konfiguracji, jest gotowy do następnego poziomu testu? Nie ma dowodzić wszystkich osiągów ani zastępować rozwoju firmware.

Należy rozdzielić:

  • bring-up podzespołu — czy PCB/driver działa;
  • integrację — czy podsystemy współpracują;
  • commissioning — czy zmontowany egzemplarz odpowiada konfiguracji;
  • qualification — czy projekt spełnia środowisko i wymagania;
  • acceptance — czy wyprodukowany egzemplarz spełnia kryteria odbioru;
  • flight test — stopniowane potwierdzenie zachowania w locie.

Eksperymentalny parametr nie powinien być zmieniany ad hoc podczas acceptance bez zapisania nowej baseline. Jeśli commissioning ujawnia defekt projektu, praca wraca do development, a po poprawce bramki są powtarzane.

Konfiguracja wzorcowa#

Jednoznaczna konfiguracja obejmuje:

  • rewizję ramy, PCB, PDB i wiązek;
  • MPN/serial FC, sensorów, ESC, silników, baterii i radia;
  • firmware z commit/build ID;
  • bootloader;
  • parametry i airframe geometry;
  • pliki kalibracji;
  • wersję GCS;
  • śmigła i kierunki;
  • payload oraz jego oprogramowanie;
  • masę i CG;
  • procedurę testową.

„Najnowszy firmware” nie jest baseline. W dniu próby aktualizacja upstream mogła zmienić domyślne parametry. Binarium powinno być zachowane z sumą.

PX4 i ArduPilot mają własne aktualne procedury konfiguracji. Artykuł opisuje strukturę procesu; dokładne nazwy parametrów należy zawsze sprawdzić w dokumentacji użytej wersji.

Karta egzemplarza#

Karta zawiera:

Pole Przykład
vehicle_id/serial trwały identyfikator
build configuration wariant ramy/payloadu
mass/CG wartość, data i metoda
firmware hash dokładne binarium
parameter hash/export baseline
calibrations ID sensorów i timestamp
battery SKU/serial/cycles
deviations zatwierdzone odstępstwa
test results link do logów/raportów
status assembled / ground-ready / flight-released

Karta nie może opierać się tylko na naklejce, którą można przełożyć. Serial jest również w pamięci/raporcie.

Każda wymiana krytycznego elementu zmienia odpowiednie pola i może cofnąć status. Wymiana FC wymaga konfiguracji i kalibracji, śmigła — inspekcji oraz testu kierunku/rodzaju, rama — drgań i geometrii.

Analiza ryzyka i go/no-go#

Przed testem wyznacza się:

  • cel i kryterium sukcesu;
  • hazardy i środki kontroli;
  • strefę, pogodę i ograniczenia;
  • role: prowadzący, operator, safety observer;
  • sposób odcięcia energii;
  • warunki przerwania;
  • plan po utracie łącza;
  • procedurę po wypadku i zabezpieczenie baterii;
  • wymagane zgody/regulacje.

Przykładowe no-go:

  • niezgodny hash parametrów;
  • niewyjaśniony reset lub prearm fault;
  • uszkodzony/napuchnięty akumulator;
  • brak logowania;
  • silnik/serwo o innym mapowaniu niż dokumentacja;
  • zbyt wysoki clipping/drgania;
  • prognoza pogody poza limitem planu;
  • brak strefy bezpieczeństwa.

Operator nie powinien być jedyną osobą obserwującą komputer, platformę i strefę. Role zależą od skali, ale obciążenie poznawcze jest realnym ryzykiem.

Inspekcja bez zasilania#

Kolejność:

  1. zgodność assembly z rysunkiem i BOM;
  2. FOD, luźne śruby, opiłki i przewody;
  3. polaryzacja baterii, PDB, BEC i kondensatorów;
  4. izolacja od carbon fiber/obudowy;
  5. strain relief i promienie wiązek;
  6. złącza zatrzaśnięte, terminal pull-back;
  7. śruby silników o właściwej długości;
  8. ruch serw/pushrodów bez kolizji;
  9. retencja baterii i payloadu;
  10. orientacja FC, GNSS i sensorów;
  11. śmigła nadal zdemontowane.

Witness marks pozwalają wykryć brak torque lub ruch po teście. Numer MPN śmigła i kierunek zapisuje się przed montażem później.

Nie poprawia się kilku znalezionych błędów bez odnotowania. Lista discrepancy pozwala wykryć problem procesu montażu.

Continuity i izolacja#

Bez baterii sprawdza się:

  • brak zwarcia szyn do masy;
  • continuity polaryzacji od złącza do PDB;
  • brak zwarć między domenami;
  • połączenie mas/powrotów zgodne ze schematem;
  • pin-to-pin krytycznych wiązek;
  • terminację CAN;
  • ekrany/chassis zgodnie z projektem;
  • rezystancję torów mocy metodą odpowiednią do miliomów.

Niska rezystancja szyny z dużymi kondensatorami może wyglądać jak chwilowe zwarcie podczas ładowania z miernika. Obserwuje się charakterystykę i porównuje z referencją, nie zgaduje.

Test hipot wykonuje się tylko, jeśli projekt go wymaga i elektronika jest przygotowana. Zwykły multimetr nie kwalifikuje izolacji wysokonapięciowej.

Polaryzację złącza mierzy się na fizycznym mating face zgodnie z rysunkiem. Kolor przewodu nie jest dowodem.

Pierwsze zasilenie#

Pierwsze zasilenie używa regulowanego źródła z ograniczeniem prądu, jeśli napięcie i moc platformy na to pozwalają. Śmigła są zdjęte, a obciążenia dołączane stopniowo.

Etapy:

  1. niskie napięcie/limit zgodny z projektem;
  2. obserwacja inrush i steady current;
  3. pomiar wszystkich szyn;
  4. kontrola temperatury elementów;
  5. weryfikacja reset/power-good;
  6. zwiększenie do nominalnego Vin;
  7. power cycle, wolna rampa i hot-plug zgodnie z planem;
  8. dopiero potem bateria z odpowiednim bezpiecznikiem/strefą.

Jeśli limit działa, nie zwiększa się go odruchowo. Najpierw porównuje się pobór z budżetem i lokalizuje źródło.

Zasilanie USB może tworzyć back-power i maskować wadliwy BEC. Testuje się osobno USB-only, battery-only i oba, obserwując reverse current.

Identyfikacja firmware i hardware#

Po połączeniu z GCS zapisuje się:

  • board ID/revision;
  • UID/serial;
  • bootloader version;
  • firmware version, commit i build options;
  • wykryte sensory oraz bus/address;
  • storage health;
  • dostępne wyjścia i protokoły;
  • reset reason.

Nie kontynuuje się, jeśli wykryty sensor różni się od BOM bez wyjaśnienia. Zamiennik IMU może mieć inny zakres, ODR lub errata.

Firmware musi oficjalnie wspierać płytkę/revizję. Wgranie targetu o podobnej nazwie może mapować piny inaczej.

Po flash wykonuje się pełny reboot z docelowego zasilania. Stan po soft reboot nie zawsze ujawnia problemy sekwencji.

Baseline parametrów#

Najbezpieczniej zacząć od znanego defaultu odpowiedniej wersji i nałożyć wersjonowany zestaw zmian. Import starych parametrów między głównymi wersjami wymaga review migracji.

Eksport parametrów ma:

  • hash;
  • firmware compatibility;
  • vehicle type/frame;
  • właściciela i datę;
  • uzasadnienie odstępstw od default;
  • status kalibracyjny.

Parametry kalibracji konkretnego sensora nie powinny być kopiowane między egzemplarzami tylko dla zgodności pliku.

Diff przed/po commissioning pokazuje przypadkową zmianę. Narzędzie powinno ignorować tylko jawnie zmienne runtime/statistics.

Orientacja i kalibracja sensorów#

Najpierw ustala się orientację FC, potem wykonuje kalibracje. Sprawdza się ręcznym ruchem:

  • roll w prawo/lewo;
  • pitch nose down/up;
  • yaw;
  • wszystkie IMU lanes;
  • zewnętrzne sensory osobno.

Kalibracja akcelerometru wymaga stabilnych pozycji i finalnego mountu. Kalibracja magnetometru odbywa się z dala od metalu/prądów, a potem testuje motor interference. Barometr i airspeed mają własne procedury.

GNSS potrzebuje czasu/fix i właściwej konfiguracji anteny. RTK obejmuje base/rover IDs, survey-in i poprawność correction link.

Kalibracja, która kończy się sukcesem UI, może nadal mieć zły residual/offset. Zapisuje się wynik i porównuje z limitami.

Nie kalibruje się przez kompensowanie usterki mechanicznej, np. mocno przechylonego FC bez dokumentacji.

Sprawdzenie health oraz redundancy#

Dla każdego sensora:

  • device ID odpowiada BOM;
  • częstotliwość i freshness są poprawne;
  • temperatura jest wiarygodna;
  • brak bus errors/FIFO overflow;
  • wartości spoczynkowe są zgodne z fizyką;
  • noise/bias nie odbiega od referencji;
  • estimator przyjmuje dane;
  • przełączenie primary jest logowane.

Redundancję testuje się kontrolowanym fault injection: wyłączenie pojedynczego urządzenia/strumienia na stanowisku lub w SITL/HIL. Nie uszkadza się fizycznie magistrali podczas lotu.

Dwa IMU na wspólnym SPI mogą utracić dane jednocześnie. Karta health powinna pokazywać wspólne zależności.

Po recovery system nie może oscylować między lane. Failsafe i log mają wskazać przyczynę.

Pomiar baterii i zasilania#

Voltage/current telemetry kalibruje się niezależnym przyrządem w kilku punktach. Sprawdza się:

  • napięcie bez obciążenia i pod obciążeniem;
  • znak i zero prądu;
  • prąd w kilku wartościach;
  • energię/coulomb count w kontrolowanym cyklu;
  • progi low/critical/emergency;
  • power-good i redundancy inputs;
  • spadek między PDB i FC;
  • brownout reset reason.

Zła liczba ogniw lub chemia prowadzi do niewłaściwych progów. Auto-detection nie zastępuje sprawdzenia.

Failsafe baterii testuje się początkowo przez symulację/wstrzyknięcie pomiaru albo regulowane źródło bez śmigieł. Nie rozładowuje się platformy w locie „aż zadziała”.

Obciążenie serw/payloadu powinno być włączone podczas transient test.

Łącza RC i GCS#

Sprawdza się:

  • mapowanie kanałów i znaki;
  • endpoints, deadband i center;
  • mode switch w każdej pozycji;
  • arming switch i kill zgodnie z projektem;
  • RSSI/LQ, frame loss i failsafe flag;
  • telemetry uplink/downlink;
  • GCS heartbeat i timeout;
  • zgodność regionu/mocy/pasma;
  • zachowanie przy restarcie nadajnika/odbiornika.

Nie testuje się zasięgu przez odlatywanie do utraty sterowania. Ground range test używa trybu producenta i kontrolowanej geometrii, a wynik nie jest prostą gwarancją zasięgu w locie.

Failsafe RC może bazować na protokole, nie na wartości kanału. Należy sprawdzić dokumentację odbiornika oraz to, co widzi autopilot.

Sterowanie przez GCS/IP ma osobny timeout i authority. Utrata jednego linku nie zawsze oznacza utratę operatora, ale maszyna stanów musi znać wymagane capability.

Konfiguracja geometrii#

Wybiera się airframe zgodny z liczbą i położeniem aktuatorów. PX4 opisuje wybór generic frame i późniejszą konfigurację geometrii/wyjść.

Każdy wirnik ma:

  • współrzędne względem body/CG;
  • kierunek osi ciągu;
  • kierunek obrotu;
  • przypisaną funkcję;
  • fizyczny output/bus;
  • min/max/reversible;
  • telemetry ID.

W niesymetrycznej ramie generic mixer może być niepoprawny. Własna macierz musi przejść testy alokacji i symulację.

Fixed-wing ma powierzchnie, znaki, neutral, travel i mechaniczne limity. VTOL dodatkowo kąty tilt oraz konfigurację faz lotu.

Mapowanie aktuatorów bez śmigieł#

PX4 i ArduPilot wyraźnie ostrzegają, by zdjąć śmigła przed motor/actuator test. Procedura:

  1. mechanicznie zdemontować śmigła i oznaczyć je;
  2. zabezpieczyć platformę;
  3. włączyć tylko funkcję testową;
  4. wywołać pojedynczy actuator na małym poziomie;
  5. dotknąć/obserwować właściwy silnik/serwo;
  6. zapisać mapping logiczny–fizyczny;
  7. wrócić do disarmed;
  8. powtórzyć każdy kanał;
  9. wyłączyć test i power cycle.

Jeśli porusza się inny motor, poprawia się output assignment, nie numer na naklejce bez aktualizacji dokumentacji.

Timer groups mogą ograniczać wspólny protokół/frequency. Silnik i serwo na jednej grupie wyjść mogą wymagać reorganizacji.

Test dowodzi mappingu w tej wersji parametrów. Po rewire lub firmware update powtarza się go.

Kierunek silników i powierzchni#

Kierunek silnika sprawdza się bez śmigła markerem/palcem z bezpiecznej odległości zgodnie z procedurą. Zmianę wykonuje się w ESC lub przez przewody fazowe zgodnie z dokumentacją napędu.

Następnie dopasowuje się śmigło o właściwym kierunku i stronę aerodynamiczną. Sam kierunek silnika nie dowodzi dodatniego ciągu.

Powierzchnie sterowe:

  • stick command daje oczekiwany ruch;
  • autopilot stabilization daje ruch przeciwny do zakłócenia;
  • neutral i travel nie powodują bind;
  • linkage nie przechodzi przez singularity;
  • pobór przy końcu nie wskazuje stall.

Tiltrotor i swashplate mają dodatkowe sprzężenia; korzysta się z procedury stacku i jigów.

Zakresy ESC i serw#

PWM/OneShot mogą wymagać kalibracji zakresu; DShot nie wymaga analogowej kalibracji endpoints, lecz nadal wymaga kierunku, idle i telemetry. Należy stosować dokumentację konkretnego ESC/protokołu.

PX4 actuator test pozwala weryfikować disarmed, minimum, maksimum i kierunek. Zasady:

  • disarmed zatrzymuje silnik;
  • minimum startuje niezawodnie, jeśli konfiguracja ma spin idle;
  • maksimum nie przekracza limitu ESC/silnika;
  • wszystkie napędy reagują podobnie;
  • telemetry RPM odpowiada numerowi.

Serwo ma neutral, min/max i reversal. Limit software pozostaje przed mechanicznym bind z marginesem. Różne mechaniczne przełożenia mogą wymagać różnych zakresów.

Kalibracji ESC nie wykonuje się ze śmigłami; nieprawidłowa sekwencja może uruchomić pełne obroty.

Test reakcji stabilizacji#

Przy rozbrojonym systemie lub bezpiecznym actuator mode, platformę porusza się i sprawdza kierunek korekty:

  • roll w prawo powinien wywołać komendę przeciwdziałającą;
  • nose down — korektę pitch up;
  • yaw — właściwą odpowiedź;
  • fixed-wing powierzchnie reagują zgodnie z trybem.

To test end-to-end: orientacja sensora, znak regulatora, mikser, mapowanie i kierunek aktuatora. Nie zastępuje osobnych testów, ale wykrywa ich niezgodność.

Bez śmigieł sygnał silnika można obserwować telemetry/oscyloskopem. Dla serw ruch jest fizyczny, ale platforma musi być zabezpieczona.

Jeśli znak jest błędny, nie próbuje się „szybkiego zawisu”. Przyczyna musi zostać usunięta na stanowisku.

Arming i preflight checks#

Preflight checks nie są przeszkodą do wyłączenia, lecz diagnostyką. Każdy błąd ma być wyjaśniony. Sprawdza się:

  • sensor health i calibration;
  • estimator readiness;
  • battery;
  • RC/GCS wymagane przez tryb;
  • home/GNSS;
  • geofence;
  • actuator/output configuration;
  • SD/logging;
  • safety switch/interlock;
  • parameters consistency.

Tymczasowe wyłączenie check może być dopuszczalne tylko w kontrolowanym teście naziemnym z zapisanym uzasadnieniem. Nie przenosi się go automatycznie do flight baseline.

Arming/disarming test obejmuje wielokrotne cykle, restart, utratę linku i powrót. Po boot system pozostaje rozbrojony.

Stan arm jest widoczny operatorowi i w logu. Fizyczne śmigła montuje się dopiero po zakończeniu wszystkich testów wymagających zdjęcia.

Failsafe#

Macierz testowa obejmuje przynajmniej:

  • utratę RC;
  • utratę GCS, jeśli wymagane;
  • low/critical battery;
  • utratę GNSS/position;
  • estimator fault;
  • geofence;
  • awarię sensora/lane;
  • watchdog/reset;
  • actuator fault, jeśli wykrywany;
  • kombinacje dwóch faultów.

Każdy test ma warunki wstępne, persistence, wybraną akcję, recovery/latch i log. Najpierw wykonuje się go w SITL, potem na rozbrojonym stanowisku lub HIL. Tylko bezpieczne, niezbędne scenariusze trafiają do lotu po analizie ryzyka.

RTL jest dostępne tylko z poprawnym home, pozycją, wysokością i zapasem energii. Utrata capability musi wybrać alternatywę.

Odzyskanie linku nie powinno automatycznie anulować krytycznego lądowania bez jawnej polityki.

Geofence, home i RTL#

Sprawdza się:

  • układ współrzędnych i jednostki;
  • promień/wysokość fence;
  • akcję naruszenia;
  • aktualizację home;
  • RTL altitude względem terenu/AGL/AMSL;
  • climb before return;
  • landing behavior;
  • brak konfliktu z przestrzenią/obiektami;
  • zachowanie bez GNSS.

Test SITL używa reprezentatywnej mapy. Polecenie RTL w otwartej symulacji nie dowodzi bezpiecznej trasy w realnym terenie.

Przed pierwszym lotem operator potwierdza home na GCS, a nie tylko ikonę GPS fix. Błędny datum lub przesunięta pozycja ma poważne skutki.

Geofence nie zastępuje planowania strefy. Jest warstwą, która również może mieć błąd.

Logowanie i czas#

Przed lotem sprawdza się:

  • utworzenie nowej sesji;
  • poprawny timestamp/UTC mapping;
  • pełny profil wymaganych sygnałów;
  • wolne miejsce i retention;
  • brak dropów przy obciążeniu;
  • odczyt pliku po power loss test;
  • build ID i parametry w metadanych;
  • markery zdarzeń/failsafe.

Krótki log naziemny pobiera się i otwiera w narzędziu. Migająca dioda SD nie jest dowodem parseable logu.

Czas wszystkich komputerów/stanowiska synchronizuje się, aby korelować video, GCS i blackbox.

Jeśli log jest warunkiem bezpieczeństwa/kwalifikacji, brak logowania jest no-go.

SITL/HIL przed lotem#

SITL uruchamia:

  • plan misji;
  • tryby i przełączenia;
  • geofence/RTL;
  • utratę linków;
  • degradację sensorów;
  • low battery model;
  • parametry ramy i alokację;
  • warunki przerwania.

HIL dodaje docelowy FC, timing, porty i wyjścia. Ograniczenia symulacji są zapisane: specjalny kanał sensorów może omijać prawdziwy driver.

Parametry SITL/HIL powinny pochodzić z tej samej baseline z jawnie koniecznymi różnicami. Ręcznie odtworzona „podobna konfiguracja” jest słabym dowodem.

Każda porażka zostawia log i test regresji. Symulacja nie upoważnia automatycznie do ryzykownego fault injection w locie.

Próba napędu#

Po zakończeniu testów bez śmigieł można wykonać zabezpieczoną próbę napędu. Wymaga:

  • stanowiska zdolnego przenieść maksymalny ciąg/moment;
  • osłon i strefy wykluczenia;
  • zdalnego odcięcia energii;
  • sprawdzonych śmigieł i torque;
  • PPE oraz planu po uszkodzeniu;
  • stopniowanego profilu RPM;
  • pomiaru prądu, napięcia, temperatury, wibracji i RPM.

Nie trzyma się multirotora ręką. Regulator może zwiększyć wyjście, a ograniczony ruch zniekształca jego odpowiedź.

Test zaczyna się od jednego napędu na dedykowanym stanowisku, jeśli projekt jest nowy, potem kompletnej platformy. Sweep zatrzymuje się przy nietypowym dźwięku, drganiu, temperaturze lub spadku.

Po próbie ponownie sprawdza się śruby, śmigła, wiązki i log.

Test naziemny i taxi#

Dla fixed-wing taxi potwierdza:

  • sterowanie kierunkiem;
  • hamulce/podwozie;
  • tracking kursu;
  • wibracje i airspeed przy prop wash;
  • link i range;
  • tryb manual/stabilized;
  • warunki przerwania przed oderwaniem.

Test nie powinien przypadkowo przejść w lot. Ogranicza się moc i wybiera miejsce zgodnie z planem.

Dla multirotora ground test obejmuje spool-up na przygotowanej powierzchni i natychmiastowe odcięcie przy tendencji do przewrócenia. Nie próbuje się „przepchnąć” błędnego znaku większym gazem.

Barometr i GNSS obserwuje się podczas napędu bez zmiany rzeczywistej pozycji.

Pierwszy zawis lub lot#

Pierwszy etap ma minimalny cel. Dla multirotora:

  1. stabilne uzbrojenie;
  2. krótki niski zawis w wydzielonej strefie;
  3. małe ruchy osi;
  4. lądowanie;
  5. rozbrojenie i analiza.

Nie łączy się od razu testu maksymalnej prędkości, autonomii i czasu lotu. Każda dodatkowa zmienna utrudnia diagnozę.

Dla fixed-wing plan startu/lotniska, prędkości i recovery wynika z analizy osiągów. Pierwszy lot nie jest miejscem do odkrycia złego CG lub reversal steru.

Warunki przerwania są konkretne: clipping, tracking, nietypowa temperatura, link, estimator warnings, oscylacja, dryf i bateria.

Obserwator nie wydaje wielu sprzecznych komend. Jedna osoba ma authority „abort”.

Analiza po próbie#

Przed kolejnym lotem analizuje się:

  • eventy, failsafe i prearm;
  • raw IMU, clipping i FFT;
  • estimator innovations/reset;
  • setpoint vs estimated rates/attitude;
  • actuator saturation i achieved control;
  • RPM/desync;
  • napięcie, prąd, sag i temperatura;
  • RC/GCS link quality;
  • GNSS C/N0/fix;
  • deadline, dropy logu i reset reason;
  • inspekcję mechaniczną.

„Dron nie spadł” nie jest kryterium sukcesu. Jeśli log ma niewyjaśniony błąd, status pozostaje wstrzymany.

Każda obserwacja dostaje disposition: normalne, limit, problem do poprawy, wymaga dodatkowej weryfikacji. Zmiany parametrów są wersjonowane.

Warto zachować video zsynchronizowane z logiem, szczególnie dla drgań, sterów i zachowania naziemnego.

Rozszerzanie obwiedni#

Obwiednię rozszerza się po jednej osi problemu:

  • większa prędkość;
  • większe przyspieszenie;
  • wiatr;
  • wysokość/temperatura;
  • payload/mass/CG;
  • tryby autonomiczne;
  • czas lotu i niska bateria;
  • awarie kontrolowane.

Każdy punkt ma wcześniejszy dowód, kryterium i back-off. Dane tworzą mapę, nie serię przypadkowych lotów.

Zmiana payloadu może cofnąć część obwiedni z powodu masy, bezwładności, EMI i oporu. Nie zakłada się pełnej kwalifikacji przez podobieństwo.

Strojenie regulatora następuje po usunięciu problemów mechanicznych/drgań i poprawnej konfiguracji napędu. PX4 standard configuration wskazuje tuning jako etap końcowy po podstawowej konfiguracji.

Odbiór i zamrożenie konfiguracji#

Po spełnieniu kryteriów tworzy się acceptance package:

  • podpisana karta egzemplarza;
  • firmware/binarium/hash;
  • eksport parametrów/hash;
  • kalibracje i sensor IDs;
  • BOM/seriale/odstępstwa;
  • masa/CG;
  • wyniki ground/flight tests;
  • log referencyjny;
  • lista limitów operacyjnych;
  • harmonogram inspekcji;
  • procedura aktualizacji i recovery.

Zamrożenie nie blokuje ulepszeń. Wymaga tylko, aby kolejna zmiana miała numer, ocenę wpływu i zakres re-testu.

Operator przed misją porównuje aktywną konfigurację z dopuszczoną. Command palette czy GCS może pokazać hash mismatch.

Egzemplarz z niewyjaśnioną różnicą wraca do statusu wymagającego commissioning.

Lista kontrolna#

  • [ ] Zdefiniowano dokładny hardware, firmware, parametry i konfigurację.
  • [ ] Karta egzemplarza ma serial, masę, CG, hash i wyniki.
  • [ ] Test ma cel, role, strefę, kryteria abort i plan awaryjny.
  • [ ] Inspekcja bez energii obejmuje polaryzację, FOD, torque i wiązki.
  • [ ] Continuity/pinout potwierdzono miernikiem, nie kolorem.
  • [ ] Pierwsze zasilenie wykonano z limitem i stopniowaniem odbiorników.
  • [ ] Zweryfikowano board ID, sensory, reset reason i storage.
  • [ ] Parametry pochodzą z wersjonowanej baseline.
  • [ ] Orientacje sprawdzono ruchem w każdej osi.
  • [ ] Voltage/current telemetry skalibrowano niezależnie.
  • [ ] Łącza i timeouty sprawdzono bez lotu do utraty zasięgu.
  • [ ] Geometria oraz mapping każdego aktuatora są udokumentowane.
  • [ ] Wszystkie testy silników wykonano bez śmigieł do właściwej bramki.
  • [ ] Kierunek stabilizacji jest przeciwny do zakłócenia.
  • [ ] Prearm faults są wyjaśnione, nie tylko wyłączone.
  • [ ] Failsafe i RTL przeszły SITL/HIL oraz bezpieczne testy naziemne.
  • [ ] Logger tworzy poprawny plik z metadanymi i bez dropów.
  • [ ] Próba napędu ma stanowisko, osłony i zdalne odcięcie.
  • [ ] Pierwszy lot ma minimalny zakres i natychmiastową analizę.
  • [ ] Konfigurację odbiorczą zamrożono wraz z dowodami.

Powiązane tematy#

Przypisy#

  1. PX4 Guide, Standard Configuration, kolejność firmware, airframe, sensorów, aktuatorów, safety i tuningu, dostęp: 2026-08-15.
  2. PX4 Guide, Actuator Configuration and Testing, geometria, output assignment, testy oraz ostrzeżenie o zdjęciu śmigieł, dostęp: 2026-08-15.
  3. ArduPilot Copter, Mandatory Hardware Configuration, frame, motor numbering, radio, sensory, ESC i failsafe, dostęp: 2026-08-15.
  4. PX4 Guide, Vibration Isolation, drgania, clipping i walidacja instalacji, dostęp: 2026-08-15.
  5. PX4 Guide, Safety and Failsafe Configuration, konfiguracja reakcji na utratę capability i awarie, dostęp: 2026-08-15.

Ostatnia aktualizacja: 2026-08-15. Ostatnia weryfikacja źródeł: 2026-08-15.

Źródła z centralnego rejestru

  1. PX4 Guide: Standard Configuration [dokumentacja projektu]
  2. PX4 Guide: Actuator Configuration and Testing [dokumentacja projektu]
  3. ArduPilot Copter: Mandatory Hardware Configuration [dokumentacja projektu]
  4. PX4 Guide: Vibration Isolation [dokumentacja projektu]
  5. PX4 User Guide: Safety Configuration and Failsafes [dokumentacja projektu]