Rozbudowa filtra wysokości przez dodanie map wysokości i lidaru pokazała niezdolność pierwszej wersji sprzętu do przechowania zadowalającej ilości map, a interfejs USB FS jest zbyt wolny, aby w rozsądnym czasie wgrać duże ilości danych do pamięci autopilota. Przez ostatnie 1,5 roku, uruchamiając kolejne funkcjonalności, na bieżąco znajdowałem i poprawiałem błędy na schemacie. Teraz nadszedł czas, w którym mam już sprawdzone wszystkie obwody i można hurtowo nanieść poprawki. Dodatkowo przymierzam się do rozpoczęcia lotów i trzeba się liczyć z możliwością uszkodzenia sprzętu, więc przydałaby się nowa wersja, którą można byłoby małoseryjnie produkować, przynajmniej na bieżące potrzeby.
Bez dużego pośpiechu przez ostatnie kilka tygodni zostawałem w pracy po godzinach, aby narysować schemat USB rozbudowanego z FS do HS poprzez interfejs ULPI, oraz większej pamięci na mapy. Efekt wygląda tak, jak na wizualizacjach poniżej:
Dla zwolenników sesji rozbieranych mam przygotowany specjalny widok:
Aby rozbudować magazyn map, przejrzałem ofertę pamięci dostępnych dla mikrokontrolera i jedyne, co wydawało się akceptowalne, to pamięć eMMC. One są w dużych obudowach BGA, ale wykorzystane jest jedynie kilkanaście linii, więc wydawało się, że powinienem dać radę podłączyć się do układu. Gdy wrzuciłem kostkę pamięci na PCB okazało się, że nie dam rady przeciągnąć nawet najcieńszej ścieżki między kulkami o rastrze 0,5 mm, nie wspominając o wstawieniu przelotki. Trzeba byłoby szukać specjalnego producenta PCB, który dałby radę zrobić tak wymagający obwód drukowany. To wiąże się z kosztami, więc moje wrodzone skąpstwo powiedziało: nie. Pamięć eMMC to jest elektronika taka jak na karcie MMC, więc zdecydowałem, że dołożę jeszcze jedno gniazdo na szybką kartę na interfejsie 4-bitowym, mogącym pracować z napięciem 1,8V. Pierwsza karta tak jak dotychczas będzie obsługiwana przez rejestrator zapisujący logi i obrazy z kamery. Druga będzie magazynem map i innych danych. Do tej pory komunikaty głosowe i konfigurację zasobów rdzenia CM7 przechowywałem na kostce NOR FLASH o pojemności 512 Mb. W nowej wersji sprzętu jej nie będzie, więc te dane będą musiały wylądować na karcie.
W pierwszej wersji sprzętu nie działała mi przetwornica 5 V. Teraz będzie użyta kostka sprawdzona wcześniej w innych projektach. Dołożone zostaną czujniki prądu, tak aby można było monitorować pobór prądu. Nadal podtrzymuję ideę zasilania pełnym napięciem pakietu do 8S. Natomiast porzuciłem obsługę analogowych czujników prądu. Obsługa czujników i ewentualnego BMS jest dostępna tylko po I2C.
Dołożone zostały gniazda umożliwiające podłączenie dwóch zintegrowanych regulatorów 4 silników. Wyrzucone zostały piny sterujące ośmioma serwami wyłącznie 50 Hz, a w ich miejsce wstawiono cztery w pełni konfigurowalne porty timera, umożliwiające podłączenie zarówno serwa jak i regulatora DShot, czy sterownika programowalnych LED-ów. Dodatkowo udało się zmniejszyć rozmiary płytki o 5 mm na długości i 2 mm na szerokości, gdyż obecnie mikrokontroler jest w mniejszej obudowie BGA. To jest mój pierwszy projekt z tak dużymi układami w obudowach BGA. Doszedłem do granic możliwości wygodnych obudów QFP i chcąc rozwijać się dalej, potrzebna była przesiadka. Mam nadzieję, że nie polegnę na tym.
Zmniejszyłem liczbę kanałów wyjściowych z 16 do 12. Wcześniej było 8 wyjść uniwersalnych podpiętych do timerów i 8 wyjść tylko dla serw multipleksowanych z jednego timera. Teraz jest 12 uniwersalnych wyjść. Ponieważ w wielowirnikowcach coraz bardziej popularne są regulatory zintegrowane 4 w jednym, posiadające 8-pinowe złącze skupiające wszystkie przewody, więc część wyjść równolegle wyprowadziłem na dwa 6-pinowe złącza zawierające masę i wyjścia czterech kanałów.
W wersji 3.0 na płytce był mikrofon cyfrowy. Wtedy skopałem footprint, więc nie udało się zrobić eksperymentów z audio, ale kontynuuję ten pomysł. W tej wersji zamiast wbudowanego mikrofonu jest wejście SAI (Serial Audio Interface) umożliwiające podłączenie do 16 mikrofonów. Macierz czujników będzie mogła być umieszczona na zewnątrz BSP i będę próbował tym narzędziem określić orientację przestrzenną źródła dźwięku. Niedawno słuchałem biografii Aleksandra Sołżenicyna, tego od Archipelagu GUŁag. On z wykształcenia był matematykiem i w trakcie I WŚ służył w artylerii przy lokalizacji pozycji strzeleckich przeciwnika metodami akustycznymi. Chciałbym być jak Sołżenicyn. Odpowiednika Archipelagu raczej nie napiszę, ale przynajmniej spróbuję słuchać jak on. Niekoniecznie będzie to artyleria, raczej inne BSP, pojazdy w pobliżu itp. Być może to przyda się do mechanizmu detekcji kolizji? Subskrybuję na Telegramie kanał ukraińskiego oddziału Посіпаки, (ukr. Minionki). Chłopaki latają bardzo nieostrożnie, wciąż zderzają się z rosyjskimi BSP. Być może określenie kierunku źródła dźwięku pozwoliłaby na większą kontrolę nad takim rendezvous w przestworzach. W zależności od preferencji można próbować autonomicznie oddalić się lub podążać za źródłem hałasu.
Zmiany są też w obsłudze kamery. Wcześniej ze względu na przepustowość ograniczyłem się do interfejsu 8 bitowego. Analiza obrazu, to nie tylko rozdzielczość, ale również dynamika jasności. Teraz mam 12-bitowy interfejs, chociaż kamery obecnie mam jedynie 10-bitowe. Nawet jeżeli nie znajdę albo nie zbuduję kamery 12-bitowej, to przynajmniej spróbuję pozyskać dostępne 10 bitów.
PS. Na początku wspomniałem o lidarze. Po 3 tygodniach czekania moje zamówienie zostało anulowane, więc musiałem zamówić kolejny i wciąż czekam.