A oto kolejny artykuł autorstwa mojego męża:

 

Choć raczej należałoby powiedzieć walka z robotem. Nawet nie z całym robotem, tylko z jego cholernym oprogramowaniem. W dzisiejszym odcinku dowiemy się co to jest SLAM i AHRS, oraz poznamy jeszcze kilka innych ciekawych akronimów.

Jak mówią posługujący się na co dzień językiem Shakespeare’a “najpierw rzeczy pierwsze”. Otóż historia ta zaczyna się na początku tego roku, gdy na swoją zgubę wpadłem na pomysł, aby mojego robocika (który jest tak naprawdę zdalnie sterowanym przez WiFi pojazdem gąsienicowym o możliwościach i wyglądzie zabawki) wyposażyć w LIDAR (ang. akronim od słów Light Detection and Ranging) i odrobinę autonomii. Po sprawdzeniu kosztów zakupu LIDARu pomysł upadł szybciej niż Pakt Stabilizacyjny za poprzednich rządów PiS. Troszkę szperania w podstawowym źródle wiedzy współczesnej ludzkości i ta-dam – dotarłem do tego, że mój pomysł jest oczywiście nie tylko niezbyt oryginalny, ale też, że ma już swoją nazwę – SLAM. SLAM to kolejny anglojęzyczny akronim tym razem od słów Simultaneous Localisation and Mapping (początkowo bałem się, że L jest od LIDAR i ciekawiło mnie jak by się zmienił ten akronim gdyby jednak użyć radaru). W internecie jest wiele ciekawych przykładów robotów, które jeżdżąc sobie po różnych pomieszczeniach jednocześnie rysują ich mapy, pomyślałem więc sobie – czemu nie… i zarzuciłem projekt.
Tak się jednak złożyło, że moja żona wraz z synami wybrali się na jakiś event z robotami jakiś czas później. Dzieciaki były zachwycone tym, co zobaczyły, a i żona była pod wrażeniem, gdy tylko wróciła zostałem zaatakowany hasłem – “startujemy w przyszłym roku!”. Se myślę… OK i przygotowuję w myślach projekt. Miałem już z grubsza obmyślone jakie chcę użyć silniki, akumulatory, jakie sterowanie i zabierałem się za projekt podwozia, gdy nieopatrznie pochwaliłem się żonie kilkoma screenami sprzętu jaki by mi się do tego przydał. Sprzęt niestety miał oprócz fotki bardzo wyraźnie napisaną cenę, tak więc zostałem wyśmiany i skierowany do wymyślenia czegoś tańszego – najlepiej na starym podwoziu, a w najlepszym wypadku na nowym ale z AliExpress. Wstępne założenia projektu właściwie legły w gruzach. Bez większego przekonania pooglądałem sobie co oferuje internet w dziedzinie gotowych podwozi do robotów i po mniej więcej tygodniu doszedłem do wniosku, że albo wydam majątek, albo kupię kolejne gówniane podwozie od zabawki. Skoro jedno już miałem, to nie było sensu zabierać się za drugie. Umyśliłem więc sobie, że powrócimy do projektu SLAM i wystartujemy w konkurencji pokonywania labiryntów. Nauczony doświadczeniem postanowiłem z tych nauk nie skorzystać i wyszukałem sobie kilka naprawdę czujników do realizacji zadania, które nie należały do najtańszych. Po konsultacji z żoną dostałem wybór – albo szukam tańszych rozwiązań, albo mam się pożegnać z tym projektem. No cóż… ponieważ piszę tą notkę, a jeszcze nie dotarłem do AHRS zapewne domyślacie się, że zacząłem coś czarować z tańszymi czujnikami. Ponieważ nie mogłem sobie pozwolić na LIDAR, kupiłem cyfrowy czujnik odległości (w dalszej części będę go nazywał dalmierzem, choć jestem przekonany, że to nie jest poprawna nazwa) z laserem podczerwonym (fajnie wychodzi na zdjęciach), oraz tzw. czujnik położenia o 10 stopniach swobody (częściej jednak używa się angielskiego skrótu DOF – Degrees of Freedom). Oba komunikują się po szynie I2C, można więc ich używać np. z Arduino czy Raspberry Pi.
Założenie było proste – z czujnika położenia ściągam położenie i orientację robota w przestrzeni, natomiast dalmierzem odległość od robota. Razem powinno mi to dać coś na kształt skanera 3D, który będzie sobie ładnie mapował wszystko punkt po punkcie tworząc sobie w pamięci zarys pomieszczenia po którym ma się poruszać. I w tym momencie powinienem wziąć łopatę i pierdolnąć się nią w łeb… Okazało się, że pomiary z czujnika 10-DOF to jakaś porażka, szyna I2C to mniejsza, ale jednak porażka, ale największą porażką okazała się dokumentacja przygotowana przez producenta czujnika. Po kilkukrotnej lekturze producenckiej papierologii ciągle nie wiedziałem jak czytać poszczególne wartości, dopiero później w otchłaniach internetu znalazłem drugi dokument (chuj wie, czemu był osobno) zawierający mapę rejestrów. Dopiero wtedy za pomocą dość zresztą wolnej szyny I2C udało mi się zebrać jakiekolwiek pomiary. Ich stabilność była mniej więcej taka sama jak pijaka po dwóch tygodniach alkoholowego ciągu, czyli żadna, a jeszcze nawet nie dotarłem do żyroskopów! Czesanie internetów ujawniło, że w zasadzie jest to normalka i te pomiary w tańszych akcelerometrach tak wyglądają (przy czym zaznaczano iż tańsze w tym wypadku oznaczają setki dolarów, a mój cały czujnik w przeliczeniu kosztował około 12$ i to z VATem), a jakiej takiej stabilności można oczekiwać po czujnikach droższych (tysiące $), z żyroskopami rzecz miała się w zasadzie podobnie. Załamany wynikami tych rozważań zacząłem rozważać porzucenie projektu, ale wrodzona niechęć do marnowania pieniędzy (przeznaczonych na czujniki) nie pozwoliła mi się poddać. Internety początkowo podsunęły dwa rozwiązania – filtr Kalmana i filtr Alfa-Beta. Pierwszy – podobno lepszy – jest całkiem nieźle opisany teoretycznie, problem jednak polega na tym, że wymaga on matmy na poziomie nie stosowanym przeze mnie od jakichś 15 lat, którą na dodatek kompletnie zapomniałem (pamiętam jeszcze tylko pojedyncze całeczki, ale równania różniczkowego już bym nie rozpykał, a – chwaląc się – byłem w tym całkiem niezły). Na dodatek próby implementacji w Excelu (na podstawie zebranych wcześniej danych) zakończyły się sromotną klęską. Ten filtr poszedł więc w odstawkę. Filtr Alfa-Beta był znacznie prostszy w teorii i implementacji, przy czym nawet dawał jakieś wyniki, ale ustabilizowanie pomiaru (ale nie będę nikogo tutaj oszukiwał – do ideału brakowało dość sporo) obnażyło problem “zanieczyszczenia” wyników grawitacją. Próby prostego, czysto teoretycznego podejścia spaliły na panewce w zasadzie już na etapie rozważań. Żeby “odjąć” grawitację, trzeba znać orientację w przestrzeni, a te cholerne żyroskopy dawały równie gówniane wyniki jak akcelerometry. Kolejna załamka i kolejny zwrot do internetów w poszukiwaniu natchnienia. Tym razem wykopałem wspomniany na wstępie AHRS.
AHRS to jeszcze jeden skrót tym razem od słów Attitude and Heading Reference System, co po naszemu można przetłumaczyć jako układ odniesienia pozycji i kursu. Okazuje się, że są nawet na to gotowe algorytmy korzystające dokładnie z danych jakie zbiera mój czujnik (i to korzystając aż z dziewięciu z nich, bo oprócz wcześniej wspomnianych dochodzi jeszcze magnetometr, który służy jako kompas). Implementacja jednego z nich (konkretnie Madgwicka – podobno najlepszy) i przesłanie wynikowego kwaternionu na mocniejszy komputer, który mógł ładnie zobrazować wyniki rozczarowywała. Dopiero jakiś przypadkowy filmik z YouTube, oraz potwierdzenie tego w dokumentacji czujnika uzmysłowiło mi, że jakiś geniusz wpadł na to, aby osie magnetometru nie pokrywały się z osiami akcelerometru/żyroskopu. Nie wiem kim był człowiek, który to wymyślił i co nim powodowało, ale serdeczne “chuj Ci w dupę” kieruję właśnie do Niego. Po skorygowaniu tego niedopatrzenia wyniki są… dalej rozczarowujące.
Dalszej części historii na razie nie opiszę z dwóch powodów – po pierwsze Google Docs (w którym powstaje ta notka) pokazuje mi, że zacząłem już trzecią stronę tekstu, a to oznacza, że jest on stanowczo za długi, a po drugie dlatego, że dotarłem w tej opowieści do punktu w którym jestem teraz. Tak, ciągle jestem w czarnej dupie, ciągle nie mam zadowalających wyników, a od SLAM jestem kilka lat świetlnych. Dobre wieści są następujące – po analizie użytego przeze mnie algorytmu AHRS doszedłem do wniosku, że może on się sprawdzać najlepiej gdy osie X i Y tworzą płaszczyznę poziomą (albo mniej więcej poziomą), natomiast Z jest skierowane w górę, lub dół. w tej chwili czujnik mam zamontowany w ten sposób, iż osie X i Y tworzą płaszczyznę pionową, ale tak mi po prostu najlepiej pasuje w płytce stykowej. Druga rzecz, która wymaga sprawdzenia to częstotliwość pomiarów. W tej chwili wykonuję około 80 pomiarów na sekundę, ale (podobno) to za mało, drugi więc kierunek działań zakłada wykorzystanie wbudowanej w czujnik 512 bajtowej kolejki FIFO dla akcelerometru i żyroskopu (algorytm Madgwicka podobno zakłada, że dane z magnetometru nie spływają, albo nie zmieniają się tak często jak pozostałe – do sprawdzenia). Bardziej liczę na pierwsze, ale jestem gotowy wprowadzić oba rozwiązania. Drugie jest o tyle gorsze, że komputerowi może zabraknąć mocy obliczeniowej na jednoczesne zbieranie danych i ich obróbkę – trzeba więc będzie wykorzystać do obliczeń drugą, mocniejszą maszynę, ale dotychczasowe próby napawają mnie umiarkowanym optymizmem. Jednym z obejść tego problemu może być przepisanie wszystkiego na któryś z języków kompilowanych, bo obecnie wszystko powstaje w Pythonie, z kolei C znam słabo i na dodatek go nie lubię… Trzeba będzie rozpoznać możliwość pisania, albo raczej kompilowania C# pod Raspberry Pi.
Jeśli ktoś kiedy trafi na tą notkę i będzie miał jakieś pytania niech się nie krępuje i zostawi komenta….