PitLab elektronika modelarska
PitLab - Elektronika modelarska
  • Strona Główna
  • Autopilot Dedalus
  • SkyAssistant
  • APL2
  • APL3
  • System FPV
  • PitLab.Sklep
  • O firmie
  1. Jesteś tutaj:  
  2. Stron główna

Co cię nie zabije, to cię wzmocni.

Szczegóły
Autor: Piotr Laskowski
Utworzono: 03 czerwiec 2026

Rozwój autopilota przez co najmniej ostatni rok to był szybki marsz do przodu. Prawie każde podejście do projektu rano przed pracą czy wieczorem tworzyło nowy fragment funkcjonalności, aż nagle coś zaczęło się psuć i spowalniać. Po kilku dniach debugowania problemu kluczowe podsystemy praktycznie przestały działać, a kod przestał się linkować. Nie jest to aż tak wielki projekt, żeby nie dało się go ogarnąć – to efekt zaledwie dwóch lat pracy. Nie jest też specjalnie skomplikowany, kilka najtrudniejszych rzeczy jest jeszcze przede mną, a mimo to narzędzie stanęło dęba i nie jestem w stanie nawet zlinkować kodu, aby zacząć szukać przyczyny. Po kilku padach nauczyłem się, jak regenerować pliki projektu, mając plik .ioc i kod źródłowy. Trzeba skasować konfigurację, wygenerować kod z CubeMX, dodać kod z GitHuba i zwykle kolejna kompilacja i linkowanie przechodzi. Jednak po kilkudziesięciu próbach nawet to przestało działać. Jeżeli nawet udało się uruchomić kod, to blokowała się komunikacja z wyświetlaczem po SPI, prawie zawsze nie działał mechanizm wymiany informacji między rdzeniami, a prędkość pętli głównej rdzenia autopilota spadła z około 230 Hz do 13 Hz, a w najgorszym etapie walki do 6,2 Hz.

Problemy zaczęły się pojawiać w chwili, gdy przyszedł zakupiony odbiornik RC pracujący na protokole Crossfire, który trzeba było dopiero oprogramować, a w tle przygotowywałem się do uruchomienia regulatorów DShot. Zimą napisałem obsługę protokołu „na sucho”. Teraz, gdy mam już regulatory i platformę, nadszedł czas, by uruchomić to na rzeczywistym sprzęcie. Na nowej platformie, czyli Pentakopterze, zamocowałem też dwa paski programowalnych LED-ów sterowane timerem przez DMA. Pierwsze przypuszczenie było takie, że uruchomiłem zbyt dużo zasobów korzystających z DMA i być może zatyka się magistrala. W mikrokontrolerze są 3 wielokanałowe układy DMA, wszystkie kanały są zajęte, spora część z nich pracuje jednocześnie, wymieniając z pamięcią duże ilości danych. Jednak testowe wyłączenie największych producentów ruchu na magistrali niczego nie zmieniło.

Może mechanizm międzyrdzeniowej wymiany danych, które rozrosły się do 350 słów 32-bitowych, wymienianych w każdym obiegu pętli głównej, tak zapychał magistralę? Jednak to nie to, ale dane zapisywane przez rdzeń CM4 przestały być widoczne dla CM7. Dostęp do pamięci jest separowany sprzętowymi semaforami, więc nie powinno być konfliktu. Ręczne zapisanie zmiennej jakąś wartością w trybie debugowania jest widoczne podczas debugowania drugiego rdzenia, ale normalna praca, tak jak było przez ostatni rok, już nie działa. Zoptymalizowałem mechanizm przejmowania pamięci, aby żaden z rdzeni nie pisał nowych danych, jeżeli nie są odczytane stare, ani nie czytał ponownie danych już wcześniej przeczytanych. To jednak nie pomogło, a ustawiane flagi też nie były widoczne dla drugiej strony.

Kolejna sprawa to wyświetlacz współdzielący magistralę SPI z panelem dotykowym i kilkoma ekspanderami IO. Każde z nich pracuje na innej prędkości, a ekspandery obsługiwane są w innym wątku niż wyświetlacz i panel dotykowy, więc dostęp do zasobu jest chroniony kolejnym semaforem. W pewnej chwili pojawiło się coś takiego, że wysyłając 3-bajtowe polecenie do układu, fizycznie wychodziły tylko 2 bajty, a magistrala wisiała. Pojawiło się to na chwilę, potem samo ustąpiło — najgorsze, co może być. Po prostu koszmar, siła złego na jednego.

Czytaj więcej: Co cię nie zabije, to cię wzmocni.

Analizator drgań i rezonansów konstrukcji BSP

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

Jakiś czas temu, szukając informacji o filtrach, znalazłem film Chrisa Rosera mówiący w drugiej części o znajdowaniu rezonansów ramy wirnikowca przy pomocy analizy FFT danych, zarejestrowanych w czasie pracy silników pochodzących z akcelerometrów i żyroskopów. Bardzo mi się to spodobało i zapragnąłem mieć taką funkcjonalność w swoim autopilocie. Od kilku lat mam własną wersję szybkiej transformaty Fouriera, opracowaną podczas rozwoju niepublikowanego testera modelarskiego. Tak więc najważniejsze elementy składowe są gotowe i można złożyć je w całość. W swojej pierwszej wersji FFT pracowało na rdzeniu Cortex 3, a wykres drgań z wybranej osi akcelerometru wyświetlany był na wyświetlaczu 320×240 pikseli. Szerokość wyświetlacza, rozmiar dostępnej pamięci i wydajność kontrolera powodowały, że rozsądną szerokością FFT było 512 punktów, umożliwiającą na wizualizację uzyskanych 256 wyników na wyświetlaczu. Wtedy rozszerzyłem możliwość konfiguracji do 1024 punktów, co wymagało uśredniania danych, gdyż na jednym pikselu ekranu musiało się zmieścić 1,6 punktów wykresu. Teraz mam troszkę większy wyświetlacz 480×320, ale to wciąż mało. Mimo to zrobiłem wykres z FFT, na tym, co jest dostępne. Dane szersze niż szerokość wyświetlacza są uśredniane a węższe rozciągane, tak aby wypełnić całą roboczą część ekranu, gdyż część ekranu zajmuje skala.

Nowością, jaką podpatrzyłem u Chrisa, jest użycie wodospadu do prezentacji danych historycznych. Wstępnie zrobiłem wodospad przechowujący 100 pomiarów, bo tyle zmieściło mi się na ekranie. Ponieważ w APL3 mam dużo dostępnej pamięci i szybki kontroler, od razu liczę 6 FFT ze wszystkich osi akcelerometru i żyroskopu. Na wyświetlaczu, aby to było w miarę czytelne, jestem w stanie narysować maksymalnie 3 wykresy. Trochę gorzej jest z wodospadem, ale rozwiązałem to w ten sposób, że każda składowa RGB odpowiada jednej osi czujnika. Intensywność świecenia każdej składowej jest proporcjonalna do wyniku transformaty, więc jeżeli szum wszystkich osi jest zbliżony do siebie, to wodospad jest w odcieniach szarości, a gdy jedna z osi zaczyna dominować nad pozostałymi, pojawia się kolorowa poświata sygnalizująca dominację drgań w danej osi. Na fotografii ekranu powyżej jest to praktycznie niewidoczne ze względu na słabe odwzorowanie kolorów.

Czytaj więcej: Analizator drgań i rezonansów konstrukcji BSP

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

Wejścia i wyjścia RC

Szczegóły
Autor: Piotr Laskowski
Utworzono: 21 marzec 2026

Przymierzając się do ulotnienia APL3, trzeba było zebrać zestaw funkcji do obsługi aparatury i sterowania silnikami, a następnie wstawić to do okienka w aplikacji. W jednym miejscu można sprawdzić, czy autopilot widzi aparaturę, skalibrować zakresy drążków, sprawdzić, czy działają silniki lub serwa. Ogólnie prosta sprawa, jednak apetyt rośnie w miarę jedzenia i w trakcie pracy pojawiło się kilka nowych pomysłów. Sporo funkcjonalności jest tylko zasygnalizowanych, ale mają zarezerwowane miejsce na rozwój. Z początkowo małego okienka wyszedł mi potwór, jak na obrazku niżej. Docelowo trzeba go będzie podzielić na osobne okna wejść i wyjść, ale zostawiam sobie trochę czasu do przemyślenia. Oprócz rzeczy znanych jeszcze z APL2, jest trochę nowości wartych omówienia.

Czytaj więcej: Wejścia i wyjścia RC

VTOL Pentakopter, czyli piąte koło u wozu

Szczegóły
Autor: Piotr Laskowski
Utworzono: 22 luty 2026

Zbliżam się do etapu wstawienia APL3 na platformę latającą. Na razie został wstawiony na 20-calową ramę wykonaną ze sklejki 3 mm, której główną zaletą jest to, że mieści się na biurku. Próbowałem uruchamiać napęd, ale mam już dosyć dłubania w kodzie, więc w ramach relaksu wymyśliłem i narysowałem nową platformę w stylu VTOL (ang. Vertical Take Off and Landing). O ile płatowiec typu delta jest trójkątnym kawałkiem płata nośnego, to dlaczego by nie zrobić płata w kształcie kwadratu i od razu wbudować w to napęd wirnikowca?

Wstępne szkice pozwoliły zauważyć, że wirnikowiec, aby lecieć do przodu, musi pochylić się do przodu. Ujemny kąt pochylenia daje składową poziomą wektora ciągu silników skierowaną do tyłu, która porusza platformę do przodu. Natomiast płatowiec zwykle leci na dodatnim kącie pochylenia, nazywanym kątem natarcia, aby uzyskać siłę nośną przez odchylenie w dół strug powietrza, a profil płata zapewnia dodatkową siłę nośną. Te dwa mechanizmy są sprzeczne. Wychodząc z neutralnej sytuacji zerowego pochylenia, jeżeli zwiększymy kąt natarcia, to kopter będzie wytwarzał składową hamującą ruch do przodu. Jeżeli pochylimy platformę, aby lecieć jak wirnikowiec, wtedy pochylony płat będzie wytwarzał siłę nośną skierowaną w dół. Być może to jest przyczyną części problemów z konstrukcjami hybrydowymi. Dlatego wymyśliłem, że zbuduję platformę ze wstępnie uniesionym płatem.

Czytaj więcej: VTOL Pentakopter, czyli piąte koło u wozu

Beczka

Szczegóły
Autor: Piotr Laskowski
Utworzono: 22 grudzień 2025

Dawno, dawno temu, w latach 80. XX wieku, za trzema rzekami: Wisłą, Bugiem i Narwią, za siedmioma górami — jednak nie, większych gór nie było po drodze. W ZSR Marianowo nauczyciel przedmiotu technologia materiałowa z jakichś niepamiętanych już względów nie mógł przyjść na lekcję, więc w jego zastępstwie przyszedł dyrektor szkoły. Nie przyszedł nauczać przedmiotu, bo prawdopodobnie nie miał czasu się przygotować, ale przyszedł spędzić ten czas z uczniami, aby nudząca się młodzież nie zdemolowała szkoły pod nieobecność nauczyciela. Zupełnie przypadkiem jednym z tych młodzieńców byłem ja.

Pan dyrektor, prawdopodobnie nie mając większego pojęcia o przedmiocie, aby zająć młodzież, przedstawił nam opowieść o beczce: Za jakiś czas, gdy skończycie studia, będziecie projektować różne rzeczy. Niektóre będą proste, inne mogą być złożonymi systemami. Musicie wiedzieć, że każdy projekt jest jak beczka, składająca się z wielu spasowanych ze sobą klepek. Każda klepka odpowiada pewnemu zakresowi wiedzy i umiejętności. Wykształcony inżynier potrafi wiele, ale w pewnych aspektach jest silniejszy, w innych orientuje się jako tako. Są też takie, na których nie zna się prawie wcale. Jeżeli przełożymy to na klepki, to jedne będą pełnowymiarowe, innym czegoś będzie brakować, np. będą miały dziury po sękach, a jeszcze inne będą krótsze, niż powinny. Jeżeli z tych umiejętności stworzymy projekt jak beczkę z klepek, to będzie można nalać do niej wody tylko do poziomu najsłabszej klepki.

Robiąc projekt, nie można skupić się na perfekcyjnym dopracowaniu tego, na czym znamy się najlepiej. Trzeba dążyć do tego, aby wszystkie klepki zostały dociągnięte do równego poziomu. Niekoniecznie od razu do wysokiego. Aby to osiągnąć, trzeba douczyć się albo zatrudnić kogoś, kto ma potrzebne umiejętności. Praca włożona w perfekcyjne dopracowanie jednego aspektu zwykle zostaje przykryta niedociągnięciami tego, na czym znamy się najsłabiej. Potrzebna jest samodyscyplina i chłodna ocena całokształtu projektu.

Czytaj więcej: Beczka

Strona 3 z 17

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

Logowanie

  • Nie pamiętasz hasła?
  • Nie pamiętasz nazwy?
  • Załóż swoje konto!

Subskrypcja

Znajdz na stronie

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