Programowanie i Robotyka
Praca zajmuje dużą część naszego dorosłego życia. W tygodniu, jeśli odliczymy czas na sen, jest to połowa dnia, a doliczając dojazdy i codzienne obowiązki – nawet więcej. Zadowolenie z pracy jest więc bardzo ważnym czynnikiem wpływającym na nasze samopoczucie. Dzisiaj zastanowię się nad satysfakcją z pracy, wypaleniem i sposobami na utrzymanie dobrego samopoczucia.
Ledwo minęła północ, a już znalazłem w necie newsa: „Z ostatniej chwili – Liroy pobił Morawieckiego”. Dotarło to do mnie dopiero po chwili – no tak, Prima Aprilis można uznać za rozpoczęty. Jeden z cytatów z internetu głosi, że 1 kwietnia to jedyny dzień w roku, kiedy ludzie zastanawiają się, czy informacje, które przeczytali, zobaczyli w telewizji, czy znaleźli w internecie są prawdziwe. Dla firm z branży IT (i nie tylko!) jest to świetna okazja, aby pokazać kreatywność i poczucie humoru swoich pracowników. Postanowiłem w tym wpisie zebrać trochę primaaprilisowych żartów.
Ostatnio w pracy miałem do wykonania dosyć proste zadanie. Chodziło o to, aby w przerwaniu od timera wykonującym się co 10 ms umieścić funkcję, która miała wykonywać się co 100 ms. W tym przerwaniu już wcześniej był wywoływany task co 10 ms i obsługa komunikacji. Napisany przeze mnie kod wyglądał mniej więcej tak:
void irq_timer_10ms(void)
{
static int32_t cnt = 0;
task_comm();
task_10ms();
cnt++;
if (cnt < 10)
{
cnt = 0;
task_100ms();
}
}
Kryje się tutaj dosyć często spotykany błąd – warunek w ifie jest odwrócony. Funkcja zamiast wywoływać się raz na 10, wykonuje się 9 razy na 10. Po dodaniu tej zmiany uruchomiłem aplikację i na pierwszy rzut oka wyglądało, że działa. Nie miałem do dyspozycji żadnych unit testów, ani dokładniejszych testów na docelowym hardware, więc wypushowałem tę zmianę razem z kilkoma innymi.
Płytka została oddana do produkcji, więc ostatnio było trochę czasu, żeby usiąść do softu. W tym tygodniu udało mi się zrobić kilka rzeczy:
Aktualny kod źródłowy projektu można znaleźć na moim GitHubie.
Płytka robota, którą ostatnio zaprojektowałem, miała kilka wad. Głównym problemem była grubość ścieżek. Praktycznie wszystkie ścieżki miały tam 10 mils. Ścieżki zasilania i inne, po których mogą płynąć większe prądy powinny być odpowiednio grube. Grubsze ścieżki zapewniają mniejszą rezystancję. Poza tym jeśli płynie nimi większy prąd, mogą się nagrzać i uszkodzić. Zdarzały mi się już takie sytuacje przy wcześniejszych płytkach, ale jakoś nie wyciągnąłem z tego wniosków. Korzystając z faktu, że płytkę dopiero co wysłałem do produkcji, postanowiłem ją przeprojektować i podesłać poprawioną wersję.
Miałem na ten tydzień zaplanowanych kilka ciekawych rzeczy. Chciałem iść na spotkanie Hackerspace Trójmiasto i napisać z tego relację oraz rozpocząć pracę nad kodem źródłowym robota. Na pierwszy ogień miał iść framework do unit testów CppUTest i konfiguracja continuous integration. Niestety plany pokrzyżowała mi choroba i przez kilka ostatnich dni prowadzę tryb życia zbliżony do kota, gdzie w ciągu doby na kilka godzin aktywności przypada kilkanaście godzin leżenia. A kiedy próbuję zrobić coś produktywnego nagminnie zdarza mi się np. otworzyć przeglądarkę i zapomnieć co chciałem znaleźć. Tym bardziej mogę być z siebie zadowolony, że cokolwiek udało mi się zrobić. Przez cokolwiek rozumiem wygenerowanie listy elementów potrzebnych do budowy robota i określenie jakie elementy mam na stanie, a jakie muszę dokupić.
Po zrobieniu schematu ideowego przyszła pora na projekt płytki PCB. Udało mi się uwinąć z tym zadaniem w weekend. W tym poście opiszę, czym się kierowałem przy projekcie PCB.
Pierwszym krokiem do stworzenia PCB było określenie wymiarów. Byłem tutaj ograniczony przez program Eagle, który wykorzystałem do zrobienia projektu. Maksymalny rozmiar płytki możliwy w darmowej wersji programu to 80x100mm. Minimalna szerokość musiała być taka, aby zmieściły się dwa mocowania silników – długość jednego to 23mm, a szerokość to 40mm. Szerokość z zamontowanymi kołami to 50mm. Ostatecznie zdecydowałem, że pomiędzy silnikami umieszczę jeszcze baterię i szerokość wyniesie 60mm. Przed mocowaniami silników po zostawieniu miejsca na koła zdecydowałem się na zwiększenie szerokości do 80mm i wyprofilowanie kształtu półkola. Wzorowałem się tutaj na istniejących robotach. Takie rozwiązanie jest standardem, a przykłady można obejrzeć tu(należy wybrać Projects->Micromouse), tu i tu. Jak bym chciał być pro, to mogłem jeszcze tam wyciąć ze środka część PCB dla odchudzenia konstrukcji. Jednak nie byłem pewny, czy się ze wszystkim zmieszczę, a dopóki nie będę chciał rywalizować z najlepszymi Micromouse na zawodach w Japonii raczej nie będę musiał dbać o każdy gram. Ostateczny kształt płytki można obejrzeć na rysunku. Obraz jest mocno zaciemniony przez żółte linie reprezentujące niedokończone połączenia, których oczywiście zapomniałem wyłączyć do screena. Jednak obrys robota i rozmieszczenie najważniejszych elementów są widoczne.
Po raz kolejny dałem się złapać na ten sam chwyt. Jak widzę, że na Helionie jest promocja, nie mogę się powstrzymać i zawsze kupuję jakąś książkę. Dobrze, jeśli kończy się tylko na jednej. Tym razem padło na „Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja” autorstwa Sandro Macuso, która została wybrana przez Helion książką roku 2017 w kategorii programowanie. O książce wiedziałem już wcześniej, ale nie byłem do niej dobrze nastawiony, ponieważ bycie rzemieślnikiem w programowaniu kojarzyło mi się ze żmudnym wyrabianiem godzin i klepaniem ciągle tego samego kodu. Ciekawe, kto chciał by napisać książkę na ten temat. Tak naprawdę ruch Software Craftsmanship promuje postawę ciągłego podnoszenia swoich umiejętności, dbania o jakość dostarczanych produktów i udoskonalania swojego programistycznego warsztatu. Celem jest dążenie do mistrzostwa w swojej profesji.
Prace nad robotem ruszyły. Dodałem pierwsze commity na GitHuba, wybrałem licencję dla projektu (tym aspektem zainteresowałem się dzięki Slackowi konkursowemu, normalnie bym olał ten temat), dodałem krótkie readme, a przede wszystkim zrobiłem schemat ideowy robota. W tym wpisie opiszę wykonany schemat.
Do wykonaniu schematu użyłem programu Cadsoft Eagle 7.2, czyli starszej wersji programu wydanej jeszcze zanim Eagle został kupiony przez Autodesk. Początkowo chciałem wypróbować nową wersję, ale stwierdziłem, że płytki projektuję raz na kiedyś, w tej wersji mam wszystko czego potrzebuję łącznie z customowymi bibliotekami elementów i poznawanie nowej wersji będzie startą czasu. Zamiast tego wolę skupić się na narzędziach programistycznych. Cały schemat prezentuje się następująco:
W kolejnych rozdziałach omówię poszczególne moduły.
W poprzednim wpisie tylko ogólnie napisałem o projekcie. Teraz przyszła pora na więcej szczegółów technicznych. Opiszę więc na czym polegają zawody Micromouse, sformułuję wymagania i przedstawię koncepcję robota.
Micromouse to jedna z konkurencji odbywających się podczas zawodów robotów. Jej celem jest jak najszybsze przejechanie robota z rogu labiryntu do mety znajdującej się najczęściej w środku labiryntu. Każdy ze startujących robotów ma określony czas, jaki może spędzić w labiryncie. Robot zaczyna od przejazdu eksploracyjnego podczas którego poznaje ułożenie ścian. Następnie wraca na start i rozpoczyna speed run, czyli jak najszybszy przejazd od startu do mety. Jeśli czas na to pozwala, robot może wykonać więcej niż jeden speed run. Podczas przejazdu możliwa jest interwencja zawodnika np. jeżeli robot się zablokuje. W takim wypadku dodawana jest kara czasowa do wyniku przejazdu. Końcowy wynik to najczęściej czas najszybszego przejazdu + kary. Na niektórych zawodach dodawany jest również całkowity czas spędzony w labiryncie podzielony przez jakiś przelicznik.
