Page 16 of 23

EKF – Rozszerzony filtr Kalmana

Poprzednio wyprowadziłem model stanowy robota i przygotowałem symulację do testowania algorytmów określania pozycji. Przyszła więc kolej na ich implementację. W tym wpisie skupię się na Rozszerzonym Filtrze Kalmana. Znajdzie się miejsce na wstęp teoretyczny oraz analizę implementacji w środowisku symulacyjnym. Starałem się wszystko opisać jak najprościej. Jednak aby wszystko dobrze zrozumieć potrzebna będzie zaawansowana wiedza z matematyki. Dobrze również wiedzieć coś o teorii sterowania. Dla mnie była to okazja do przypomnienia sobie co nieco ze studiów i wyprowadzenia kilku wzorów na kartce.

Continue reading

Regulator prędkości obrotowej

W końcu udało mi się zakończyć pracę nad regulatorem prędkości obrotowej robota, z którym walczyłem od dłuższego czasu. W poprzednich wpisach opisywałem problemy z żyroskopem i spalenie płytki, co wiązało się z nowym projektem PCB. Nareszcie udało doprowadzić się temat do końca. We wpisie znajdziecie trochę matmy, dużo wykresów i opis kolejnych przygód z zepsutym hardwarem.

Continue reading

Kiedy od softu zależy ludzkie życie – o systemach bezpieczeństwa

W internecie można spotkać głosy, że programiści nie wykonują odpowiedzialnych zadań i nie ma żadnych regulacji, których muszą przestrzegać. Bo co złego może się stać, jeśli strona nie będzie działać, albo komputer wywali bluescreena. W końcu świat się od tego nie zawali. Być może jest to prawdą w 99% projektów programistycznych. Jednak tam, gdzie na szali jest ludzkie życie, bardzo restrykcyjne regulacje obowiązują już od dawna. Wiem o czym mówię, ponieważ przez ostatnie dwa lata pracowałem przy systemie sterującym ruchem pociągów.

Continue reading

Zabawy z folią aluminiową

Po zlutowaniu nowego PCB, zgodnie z planem opisanym poprzednio, przystąpiłem do strojenia regulatorów silników. O ile z ruchem postępowym poszło szybko – w końcu robiłem to już któryś raz – tak z ruchem obrotowym natrafiłem na kolejne problemy. Jako sprzężenie zwrotne dla regulatora używam żyroskopu i okazało się, że odczyty są mocno zaszumione. Zakłócenia są obecne tylko przy podłączonych silnikach. Głównym podejrzanym jest pole elektromagnetyczne generowane przez silniki. W ruch poszła więc tytułowa folia aluminiowa. Efekty były dosyć komiczne.

Continue reading

Micromouse ma nowe PCB

Pracując nad regulatorami silników zrobiłem zwarcie na płytce czyniąc ją niezdatną do użytku. Pisałem o tym w poprzednim tekście o Micromouse – link. Miałem w zapasie jeszcze części i PCB, więc przystąpiłem do lutowania. Niestety na drugiej płytce również miałem problemy z poprawnym działaniem robota. Przy okazji spaliłem programator ostatecznie tracąc szanse na sprawdzenie czegokolwiek na sprzęcie. Przyszła więc pora na zrobienie nowej wersji płytki. Poza tym miałem problem z jednym mocowaniem kół – w konkretnym ułożeniu zębatek stawiało ono opór i w rezultacie nie kręciło się tak dobrze jak drugie. Na tych dwóch rzeczach skupiałem się w swych ostatnich pracach nad robotem.

Continue reading

Projekt jak wyścig kolarski

W dobie Agile projekty informatyczne są często traktowane jako wiele następujących zaraz po sobie sprintów. Można się spotkać z głosami, że taki projekt to raczej maraton, gdzie powinniśmy się skupiać na celu w dłuższej perspektywie. Jednak indywidualny bieg nie oddaje dobrze wielu niuansów związanych z współpracą w zespole, dużo lepszym porównaniem jest wyścig kolarski.

Continue reading

TDD embedded – system buildowania

Podstawą TDD jest szybki feedback jaki otrzymujemy z unit testów. Oznacza to, że kompilacja i uruchomienie testów powinno trwać kilka sekund. Kluczem do osiągnięcia tak krótkiego czasu jest odpowiednio skonfigurowany system buildowania. Wiadomo, że w te kilka sekund nie uda nam się zbudować od zera całego projektu. System buildowania musi więc udostępniać nam odpowiednie opcje. W tym wpisie postaram się je przybliżyć. Będę pisał z punktu widzenia systemów embedded, ale część uwag spokojnie można odnieść do zwykłych aplikacji.

Continue reading

Proces TDD dla systemów embedded

Aby mikrocykl TDD Red-Green-Refactor był efektywny, kompilacja i wykonanie testu powinny trwać kilka sekund. W praktyce oznacza to, że testy nie są wykonywane na docelowej platformie i należy podjąć dodatkowe kroki w celu wykrycia ewentualnych problemów związanych ze sprzętem. W poprzednim wpisie wytłumaczyłem jak może w tym pomóc dual targeting. Dzisiaj opiszę jak powinien wyglądać proces tworzenia oprogramowania, aby minimalizować ryzyko związane ze sprzętem. Proces ten jako pierwszy opisał James Grenning (prowadzi świetnego bloga o TDD Embedded – link) w swojej książce „Test Driven Development for Embedded C”. Zaproponował on Embedded TDD Cycle składający się z pięciu kroków.

Continue reading