Programowanie i Robotyka
W ostatnim czasie działo się u mnie bardzo dużo. Co prawda w mojej aktywności online nie znalazło to zupełnie odzwierciedlenia, stąd prawie trzytygodniowy zastój na blogu. Ale pora wrócić do regularnego pisania. Pomysłów na nowe treści nie brakuje. Dzisiaj zapraszam na małe sprawozdanie z kilku ostatnich tygodni. Będzie więc o długim wyjeździe, zmianie projektu, pierwszym przeprowadzonym szkoleniu zewnętrznym i o rowerze.
Pisząc unit testy chcielibyśmy wiedzieć, czy robimy to wystarczająco dobrze i czy dodajemy w ten sposób wartość do projektu. Informacja ta jest potrzebna programistom, aby mogli doskonalić swój warsztat i ułatwiać pracę zespołowi. Korzystają z niej również managerowie planując zadania, skład zespołu itp. Najczęściej wykorzystywaną metryką jest tutaj test coverage, jednak niesie ona jedynie ograniczoną informację. Ważne są również miary empiryczne, które ciężko przedstawić w formie liczbowej.
Nieodłącznym elementem TDD i unit testów jest mockowanie zależności. Powstało w tym celu sporo bibliotek dla różnych języków i różnych frameworków testowych. Mogłoby się więc wydawać, że wystarczy wybrać swoją ulubioną bibliotekę do mocków i po prostu jej używać. Okazuje się jednak, że pisanie prostych mocków samemu czasem może okazać się lepszym wyborem. Pokażę dzisiaj jak łatwo można napisać własne mocki do frameworków Unity i CppUTest.
Aby móc testować aplikacje embedded na platformie docelowej często potrzebujemy frameworka napisanego w czystym C. Najlepiej jeszcze, aby zajmował mało miejsca w pamięci i był jak najprostszy, aby dawał się skompilować na kompilatorach bez zaawansowanych opcji i funkcji bibliotecznych. Wymagania te spełnia framework Unity. Niestety nazwa jest dosyć niefortunna, pokrywa się z Unity do tworzenia gier i ciężko np. wyszukiwać teksty o frameworku w google.
Aby stosować Test Driven Development potrzebujemy odpowiedniego frameworka testowego implementującego obsługę scenariuszy i grup testowych, drukowanie outputu, czy asserty. Mimo iż brak takiego frameworka nie może być wymówką, aby nie testować (najmniejszy framework w C składa się z 3 linii kodu!), dobre narzędzie ułatwi nam pracę i zwiększy produktywność. Dzisiaj opiszę dość ciekawe podejście do testowania projektu napisanego w C – wykorzystanie frameworka w C++. A jest nim CppUTest.
Jedną z największych zalet procesorów STM32F4 i ogólnie Cortex-M4 jest jednostka Floating Point Unit (FPU) przyspieszająca obliczenia na liczbach zmiennoprzecinkowych. Jej wykorzystanie wymaga od użytkownika włączenia FPU podczas działania programu oraz kompilacji z odpowiednimi flagami, aby używać instrukcji FPU. W tym wpisie omawiam jak obsługiwać FPU zarówno od strony programu jak i kompilatora oraz jak pisać kod, aby mieć pewność, że wykorzystuje on dobrodziejstwa FPU.
Dzisiaj opiszę problem orientacji mapy labiryntu, czyli odniesienie mapy do kierunków w przestrzeni i do numeracji pól. Co ciekawe, z początku w ogóle nie zdawałem sobie sprawy, że jest to ważna decyzja projektowa, która może ułatwić lub utrudnić dalsze prace. Po prostu myślałem, że numeracja jest prowadzona w jedyny słuszny sposób wykorzystywany we wszystkich innych dziedzinach. Dopiero później zdałem sobie sprawę, że moja mapa nie jest kompatybilna z narzędziami udostępnianymi w internecie. Dalej również okazało się, że nie jest ona optymalna nawet do moich zastosowań.
W dzisiejszym wpisie prześledzimy całą drogę od pomiaru odległości przez czujnik ściany do ostatecznego dodania tej ściany do mapy labiryntu w pamięci robota. Na tej drodze znajduje się wiele akcji pośrednich takich, jak określenie współrzędnych wykrytej ściany, czy potwierdzenie wykrycia w kilku pomiarach.
Ostatnio przeczytałem książkę „Wojny konsolowe. SEGA, Nintendo i batalia, która zdefiniowała pokolenie” autorstwa Blake J. Harrisa. Była to okazja, by przenieść się do świata gier z początku lat 90-tych. Zaczęto wtedy odkrywać, że gry to nie jest chwilowa moda, ani rozrywka tylko dla małych dzieci, tylko potężna gałąź przemysłu o ogromnym potencjale.
Ostatnio mocno pogłębiłem wiedzę dotyczącą algorytmów SLAM. Krótkoterminowym celem jest oczywiście inspiracja przy tworzeniu jak najlepszego sposobu lokalizacji i nawigacji w robocie Micromouse. W dzisiejszym wpisie przedstawię różnice między Micromouse, a typowym problemem SLAM oraz pomysły na implementację będące konsekwencją tych różnic.