PitLab elektronika modelarska
PitLab - Elektronika modelarska
  • Strona Główna
  • Autopilot Dedalus
  • SkyAssistant
  • APL2
  • APL3
  • System FPV
  • PitLab.Sklep
  • O firmie
    • Polityka prywatności odnoszącą się do tzw. plików Cookies
  1. Jesteś tutaj:  
  2. Stron główna
  3. O firmie
  4. Polityka prywatności odnoszącą się do tzw. plików Cookies
  5. Projekty

Projekty

Artykułu opisujące projekty Pitlaba

Czy warto wspominać o błędach?

Szczegóły
Autor: Piotr Laskowski
Utworzono: 27 lipiec 2026

Uważam, że podczas rozwoju jakiegokolwiek projektu, występowanie błędów jest czymś normalnym. Jest wartością zasilającą sprzężenie zwrotne w pętli doskonalenia produktu. Im efektywniejszy będzie proces ich znajdowania, tym szybciej projekt osiągnie dojrzałość. Już w trakcie implementacji obsługi błędów znalazłem kilka problemów, z których wcześniej nie zdawałem sobie sprawy. Debugowanie wymusza ponowny przegląd kodu mającego nierzadko kilka lat. Spojrzenie na niego jeszcze raz z nowej perspektywy pozwala zauważyć nowe rzeczy. Można to porównać do gry, w której trzeba znaleźć drogę w labiryncie pełnym pułapek. W pierwszej kolejności trzeba zbudować sobie w głowie mapę zauważonych pułapek. Nigdy nie wiadomo, czy wszystkie już zostały znalezione. Powstający kod jest opisem przejścia przez ten labirynt. W kodzie opis pułapek jest zwykle pomijany, czasami jest coś wspomniane w komentarzu, ale w ogólności przy powtórnej wizycie w tym miejscu trzeba zbudować mapę jeszcze raz. Ponieważ ścieżka jest już wyznaczona, spojrzenie na labirynt jest zupełnie inne, niż wtedy gdy patrzyliśmy na niego za pierwszym razem. Nierzadko można znaleźć lepszą drogę. Dlatego warto wracać do kodu, a już na pewno wtedy, gdy stwarza on zauważalne problemy.

W złożonym systemie, jakim jest APL3, mającym wiele trybów pracy i obsługującym wiele poleceń, jest prawdopodobne, że mogą nastąpić okoliczności, w których pewne mechanizmy nie będą działały tak, jak powinny. Przyczyną może być nieoczekiwana konfiguracja, błąd czujnika czy nieprzystosowanie kodu do zmienionych warunków pracy. Wystąpienie takich sytuacji jest ewidentnym błędem i warto byłoby mieć świadomość, że taka sytuacja ma miejsce. Można wtedy zareagować, poprawiając oprogramowanie lub zmieniając warunki pracy. W przypadku rdzenia CM7, mającego swój interfejs użytkownika, informację o błędzie można wyświetlić jako komunikat na ekranie, ale jak poinformować o sytuacji z błędem w rdzeniu CM4?

Czytaj więcej: Czy warto wspominać o błędach?

Regulatory PID

Szczegóły
Autor: Piotr Laskowski
Utworzono: 23 lipiec 2026

Obiektem odpowiedzialnym za utrzymanie stabilności lotu jest regulator proporcjonalno-całkująco-różniczkujący, nazywany skrótowo PID od pierwszych liter angielskich nazw tych trzech członów. Regulator porównuje wartość zadaną wz, czyli taką wartość regulowanego parametru, jaką chcemy osiągnąć, z wartością wejściową x otrzymaną z układu pomiarowego, reprezentującą rzeczywistą wartość regulowanego parametru. Regulator oblicza różnicę między tym, co ma być, a tym, co jest, nazywaną błędem lub uchybem regulacji e. Błąd jest następnie przetwarzany w poszczególnych członach regulatora, aby obliczyć wartość wyjściową y, przekazywaną na układy wykonawcze sterujące regulowanym parametrem. W bezzałogowcach czujniki znajdują się w jednostce inercyjnej mierzącej prędkości kątowe i kąty orientacji w przestrzeni. Czujniki w centralce barometrycznej mierzą wysokość, na podstawie której obliczana jest prędkość zmiany wysokości, oraz prędkość względem powietrza. Jeszcze inne mierzą położenie w przestrzeni i prędkość zmiany tego położenia. Układami wykonawczymi w bezzałogowcu są silniki lub powierzchnie sterowe. Wartości zadane w zależności od trybu regulacji pochodzą z aparatury RC w przypadku sterowania ręcznego, z układu automatyki lotu, który wyznacza zadane wartości parametrów lotu na podstawie zdefiniowanej trasy lotu, lub z członów nadrzędnych w przypadku kaskady.

Regulator pracuje z rzeczywistymi wartościami regulowanych parametrów. Jeżeli stabilizuje prędkość zmiany wysokości, to jego wartość zadana i wartość wejściowa są podawane w jednostkach pomiaru tej prędkości, czyli w metrach na sekundę [m/s]. Jeżeli stabilizuje wysokość, to wartości podane są w metrach [m]. Jeżeli regulator stabilizuje kąt, to obie wchodzące do niego wartości są podane w radianach [rad]. Prędkości kątowe są podane w radianach na sekundę [rad/s]. Współrzędne geograficzne są również kątem podanym w radianach [rad]. Analogicznie prędkość zmiany położenia jest wyrażona w radianach na sekundę [rad/s]. Dlaczego radiany, a nie stopnie? Ponieważ jednostką miary kąta w układzie SI jest radian i w tej jednostce wykonywane są obliczenia trygonometryczne. Przyjąłem, że wszystkie kąty będą wyskalowane w radianach a ewentualne przeliczenie ich na bardziej intuicyjne stopnie odbywa się w interfejsie użytkownika.

Wartość wyjściowa regulatora jest wynikiem przekształceń różnicy parametrów wejściowych. Ponieważ obiekty wykonawcze nie są wyskalowane w konkretnych jednostkach, więc wyjście regulatora jest normalizowane do zakresu ustalonego przez użytkownika, domyślnie ±100,0.

Czytaj więcej: Regulatory PID

Wymiana informacji między rdzeniami kontrolera

Szczegóły
Autor: Piotr Laskowski
Utworzono: 13 lipiec 2026

Każdy współczesny komputer osobisty czy smartfon ma procesor z więcej niż jednym rdzeniem. Prognozuję, że wkrótce podobnie będzie z autopilotami, więc już teraz zdecydowałem się na dwurdzeniowy mikrokontroler, pomimo że współczesne autopiloty radzą sobie z jednym. Dzisiaj sobie radzą, ale jutro mogą potrzebować więcej, więc teraz jest czas na zdobycie doświadczenia i wypracowanie narzędzi do obsługi wieloprocesorowości.

Mikrokontroler w APL3 ma dwa rdzenie: CM7, czyli Cortex-M7 – szybki i nowoczesny jak na kontrolery rdzeń, pracujący z częstotliwością 480 MHz, obsługujący dużą ilość pamięci, oraz CM4, czyli Cortex-M4 – tradycyjny rdzeń będący rozszerzeniem popularnego Cortex-M3 o jednostkę zmiennoprzecinkową, pracujący z częstotliwością 240 MHz. Jako punkt odniesienia weźmy System FPV w wersji 2.x, gdzie kontroler miał rdzeń Cortex-M3 pracujący na 72 MHz, albo APL2 również z Cortex-M3 pracującym na 120 MHz, gdzie ich wydajność spokojnie wystarczała, aby można było latać. 

Podstawowym wyznacznikiem wydajności autopilota jest prędkość aktualizacji jego pętli głównej, czyli cyklu obsługi wszystkich czujników, a w szczególności czujników jednostki inercyjnej IMU, pozwalającej na wyznaczenie orientacji w przestrzeni i aktualizacji swojej pozycji przez mechanizmy wykonawcze, czyli serwa lub silniki. W APL3 pętla główna obecnie jest aktualizowana z częstotliwością ok. 1900 Hz. Rdzeń CM4 obsługuje właściwy autopilot z wyłączeniem obsługi loggera na karcie SD i telemetrii. Rdzeń CM7 obsługuje multimedialny interfejs użytkownika, kamerę i obróbkę obrazu oraz czujniki zbliżeniowe: sonary i lidary. Docelowo CM7 ma również wyznaczać trasę lotu dla CM4 na podstawie danych ze swoich czujników, w szczególności obrazowego rozpoznania trasy lotu. Ze względu na różnorodność obsługiwanych funkcjonalności pracuje pod kontrolą systemu operacyjnego RTOS, obsługując wiele wątków, więc tutaj trudno mówić o częstotliwości obsługi, gdyż jest ona inna dla każdego wątku.

W sytuacji, gdy CM4 ma komplet informacji o stanie autopilota, a CM7 obsługuje interfejs użytkownika, w tym logger i telemetrię, pojawia się potrzeba wymiany informacji między nimi. Zostało to zrobione na bazie wspólnej pamięci SRAM4. W 2 kB zarezerwowanej w tym celu pamięci są zdefiniowane 2 tablice danych typu uint32_t: nBuforWymianyCM4[] i nBuforWymianyCM7[]. Każdy z rdzeni ma swoją kopię tych buforów w postaci unii uDaneCM7 i odpowiednio uDaneCM4, łączących powyższe tablice uint32_t oraz struktury danych wychodzących z każdego rdzenia. Unia jest po to, aby z jednej strony móc zapisać w niej dane o dowolnym typie i rozmiarze, a z drugiej strony móc efektywnie wykonać transfer danych do i ze wspólnej pamięci pełnymi 32-bitowymi słowami. Co kilka obiegów pętli oba rdzenie zapisują swoje dane do wspólnego bufora wymiany i odczytują dane drugiego rdzenia.

Czytaj więcej: Wymiana informacji między rdzeniami kontrolera

Odbiorniki RC

Szczegóły
Autor: Piotr Laskowski
Utworzono: 20 kwiecień 2026

Aby zwiększyć niezawodności łącza radiowego, APL3 może jednocześnie obsługiwać 2 odbiorniki RC np. pracujące na różnych częstotliwościach. Odbiorniki podłączane są do dwóch pierwszych kolumn szpilek tradycyjnego, 3-szpilkowego złącza RC zasilanego przefiltrowanym napięciem 5V. Filtr typu podwójne π ma za zadanie odseparowanie zakłóceń mogących występować na magistrali zasilania do odbiorników, gdyż zasilanie odbiornika zaszumionym napięciem może powodować zmniejszenie jego czułości odbioru.

Rys 1. Obwód filtru zasilania odbiorników RC

 W zależności od wybranego protokołu transmisji dane mogą być analizowane przez timer np. sygnał PPM, lub odbierane przez UART np. S-Bus, CrossFire. Rodzaj obsługiwanego protokołu musi być zdefiniowany w konfiguracji wejść i wyjść RC. Patrz Rys 2.1.

Rys 2. Konfiguracja odbiorników RC. 1) definicja typu i formatu wejścia, 2) definicje funkcji kanałów podstawowych, 3) definicje funkcji kanałów rozszerzonych

Ponieważ różne formaty mają różną rozdzielczość i zakres sygnału RC, po odebraniu są one normalizowane. Jako normę przyjęto skalę z zakresu od 0 do 2000. Pozycja neutralna drążka 0% odpowiada wartości 1000. Jeden procent wartości sygnału odpowiada liczbie 8. Sygnały z różnych odbiorników mogą być porównane ze sobą dopiero po normalizacji ich zakresu. Do dalszej analizy przechodzi sygnał z odbiornika o niższej stopie błędów.

Procentowe wysterowanie -125% -100% -50% -25% 0% +25% +50% +100% +125%
Wartość liczbowa normy 0 200 600 800 1000 1200 1400 1800 2000

 

Pierwsze 4 kanały pełnią wyłącznie funkcje sterowania. Ze względu na to że różne typy aparatur (w szczególności te starsze) mogą mieć różne przypisanie funkcji do kanałów, w oknie konfiguracji wejść umożliwiono wskazanie numerów kanałów, tak aby po przestawieniu miały układ wymagany przez autopilot, tak jak jest to pokazane na Rys 2.2.

W autopilocie przyjęto układ kanałów odpowiadający obróbce danych w kolejności w jakiej występują w czujnikach, czyli kanał pierwszy steruje przechyleniem, co odpowiada osi X żyroskopu, kanał drugi steruje pochyleniem, co dopowiada osi Y żyroskopu, kanał trzeci steruje odchyleniem, co dopowiada osi Z żyroskopu. Ostatni kanał jest odpowiedzialny za wysokość.Takie ułożenie kanałów pozwala obrabiać wszystkie informacje w jednej pętli.

Kanały o numerze wyższym niż 4 nie mają przypisanej standardowej roli. Można zdefiniować dla nich jedną z przewidzianych funkcji. Kanały z precyzyjnymi potencjometrami mogą służyć do strojenia regulatorów PID zadając wartość wybranego parametru w określonych przez użytkownika granicach. Kanały podpięte pod przełączniki 2-położeniowe mogą sterować wsokoprądowymi wyjściami typu otwarty dren (OD), mogą uruchamiać wypowiedzenie komunikatu. 

Każdy kanał wejściowy może być przepisany na dowolne wyjście RC, tak aby sterować np. gimbalem. Przypisanie kanałów wejściowych do wyjść, odbywa się w konfiguracji wyjść RC.

Publikacja schematu i kodu SkyAssiatanta

Szczegóły
Autor: Piotr Laskowski
Utworzono: 01 kwiecień 2026

Minęło dużo czasu, odkąd wariometr nie jest już produkowany, jednak wciąż zdarzają się pytania o jego dostępność. Nie jestem w stanie wznowić produkcji, z przyczyn technologicznych i finansowych, ale mogę opublikować schemat i źródła. Jeżeli kolejne pokolenia modelarzy będą chciały zaczerpnąć pomysł na budowę współczesnej wersji urządzenia, to wyrażam zgodę na korzystania z moich rozwiązań. Niech to będzie prezent z okazji 21 lat istnienia firmy. Schemat wygląda następująco (kliknij obraz, aby pobrać PDF): 

Czytaj więcej: Publikacja schematu i kodu SkyAssiatanta

  1. Kalibracja żyroskopów
  2. Kalibracja czujnika ciśnienia bezwzględnego
  3. Kalibracja magnetometrów
  4. Repozytoria APL3

Podkategorie

Komputer pokładowy Liczba artykułów:  30

Zagadnienia związane z komputerem pokładowym AutoPitLot

Wariometr SkyAssistant Liczba artykułów:  9

Zagadnienia związane z wariometrem SkyAssistant

System FPV Liczba artykułów:  14

Zawiera informacje o systemie przeznaczonym d lotów FPV skłądajacym się z OSD (On Screen Display) czyli graficznej nakładki na obraz przesyłany z kamery, Autopilota dla bezzałogowych systemów latających oraz stacji naziemnej odbierającej telemetrię z bezzałogowego samolotu, wyposażonej w sterownik anteny śledzącej, diversity i loger.

Interfejs FMS Liczba artykułów:  4

Zagadnienia związane z interfejsem do modelarskiego symulatora FMS

Diversity RC Liczba artykułów:  1

Naglowki do zakladek Liczba artykułów:  5

Firma Liczba artykułów:  7

Zagadnienia związane z działalnością firmy Pitlab

Autopilot Dedalus Liczba artykułów:  3

Hermes Liczba artykułów:  1

Strona APL3 Liczba artykułów:  10

Artykuły tworzące widok strony APL3

Strona 1 z 9

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

Znajdz na stronie

Copyright © 2026 PitLab elektronika modelarska. Wszelkie prawa zastrzeżone.
Joomla! jest wolnym oprogramowaniem wydanym na warunkach GNU Powszechnej Licencji Publicznej.