Page 2 of 9

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.

Czytaj dalej

Początek prac nad estymatorem pozycji robota

Mając gotowe regulatory prędkości silników mogę przystąpić do modułu estymacji pozycji. W tym wpisie umieszczę garść ogólnych informacji dotyczących pracy estymatora, a także wyprowadzenie modelu matematycznego robota, który będzie potrzebny do wewnętrznych obliczeń.

Czytaj dalej

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.

Czytaj dalej

Systemy bezpieczeństwa – sposoby przeciwdziałania błędom

W poprzednim artykule opisałem trochę podstawowych informacji dotyczących systemów bezpieczeństwa. Skupiłem się tam na podstawowych pojęciach i procesach. Dzisiaj mam zamiar omówić kilka aspektów technicznych. Będzie więc o tym jak takie systemy zachowują się w przypadku wykrycia błędu i jak minimalizują efekty ich wystąpienia.

Czytaj dalej

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.

Czytaj dalej

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.

Czytaj dalej

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.

Czytaj dalej

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.

Czytaj dalej

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.

Czytaj dalej

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.

Czytaj dalej

© 2018 ucgosu.pl

Theme by Anders NorénUp ↑