Projekt zespołowy robota wykonującego zadanie

Najpierw etapy, potem klocki

Zadania „przewieź ładunek ze startu na metę” nie da się przetestować. Jest za duże. Jeśli robot nie dojedzie, przyczyn może być pięć naraz i żadnej z nich nie sprawdzisz osobno. Dlatego pierwszą czynnością w projekcie nie jest budowanie, tylko rozbicie zadania na etapy.

Etap ma być na tyle mały, żeby dało się go uruchomić samodzielnie i zobaczyć wynik w kilka sekund. Dobre etapy dla zadania transportowego wyglądają tak: dojedź do ładunku, zgarnij albo chwyć ładunek, przejedź prosty odcinek, wykonaj skręt, dojedź do mety, zostaw ładunek. Zły etap brzmi „przejedź trasę”, bo mieści w sobie cztery poprzednie i nie mówi, co dokładnie ma się wydarzyć.

Dobrym testem jakości etapu jest pytanie: czy potrafię powiedzieć jednym zdaniem, po czym poznam, że ten etap się udał. Jeśli tak, etap jest wystarczająco mały. „Przejedź 40 centymetrów do przodu i zatrzymaj się przed linią” przechodzi ten test. „Zrób część z ładunkiem” nie przechodzi.

Kolejność ma znaczenie także dlatego, że lista etapów decyduje o tym, co w ogóle budujecie. Zespół, który zaczyna od efektownej konstrukcji, często buduje chwytak, choć do zadania wystarczy płaska ścianka zgarniająca ładunek przed robotem. Etapy najpierw, klocki potem.

Trzy role i po co je zapisywać

W zespole trzyosobowym prawie zawsze zdarza się to samo: jedna osoba przejmuje laptop, a dwie patrzą. Efekt jest podwójnie zły. Ci, którzy patrzą, niczego się nie uczą, a ten przy klawiaturze nie ma kto sprawdzać i zapisywać wyników, więc sam zapomina, co zmienił przed poprzednią próbą.

Trzy role rozwiązują ten problem. Konstruktor odpowiada za model: koła, chwytak, rozłożenie ciężaru. Programista układa i zmienia bloki. Tester uruchamia próby i zapisuje wyniki, i to jest rola najważniejsza, a nie zapasowa, bo bez zapisu praca całego zespołu nie zostawia po sobie żadnej wiedzy.

Role można zamieniać w trakcie i warto to robić, żeby każdy dotknął każdej części zadania. Zamianę trzeba jednak zapisać, bo inaczej po pół godzinie nikt nie odtworzy, kto co sprawdzał. Przy każdej roli warto też zanotować, za który etap ta osoba odpowiada. Wtedy zdanie „to nie działa” zamienia się w konkretne „etap trzeci nie działa i zajmuje się nim Kuba”.

Obroty zamiast sekund

Najczęstszy sposób sterowania ruchem to ustawienie czasu jazdy: jedź przez dwie sekundy. Działa to za pierwszym razem i przestaje działać po kilkunastu minutach pracy. Powód jest prosty: prędkość silnika zależy od poziomu naładowania baterii. Ten sam program przy pełnej baterii przejedzie dalej niż przy baterii wyczerpanej w połowie, więc robot, który rano trafiał w linię, po południu jej nie dojeżdża.

Powtarzalne sterowanie opiera się na obrotach silnika, a nie na czasie. Jeden obrót to zawsze ten sam kąt, więc przy tych samych kołach zawsze ta sama droga, niezależnie od baterii. Żeby z tego skorzystać, potrzebujesz jednej liczby: ile centymetrów przejeżdża Twój robot na jeden obrót silnika. Bez niej ustawiasz obroty na oko i wracasz do zgadywania, tylko w innej jednostce.

Pomiar jest krótki. Ustaw robota tak, żeby przód wypadał dokładnie przy krawędzi kartki albo przy linii. Uruchom program z jednym obrotem silnika. Zmierz miarką drogę, którą pokonał. Zapisz tę liczbę, bo od tej chwili każdy odcinek trasy przeliczasz na obroty: dzielisz długość odcinka przez drogę na jeden obrót.

Jest jeszcze jedna korzyść. Gdy znasz tę liczbę, potrafisz sprawdzić, czy problem leży w programie, czy w mechanice. Jeśli robot ma przejechać 40 centymetrów, program zadaje właściwą liczbę obrotów, a robot jedzie 33 centymetry, to nie program jest winny, tylko poślizg kół albo zbyt duże obciążenie.

Jedna zmiana, jedna próba, jeden zapis

Kiedy robot nie robi tego, co ma, naturalnym odruchem jest poprawienie kilku rzeczy naraz: podkręcenie prędkości, przesunięcie kół i zmiana dwóch parametrów w programie, a potem uruchomienie. Jeśli po takiej serii przejazd się uda, zespół nie ma żadnej wiedzy. Nie wie, która zmiana pomogła, więc nie potrafi jej powtórzyć ani zastosować przy następnym problemie. Udany przejazd, którego nie umiesz powtórzyć, jest wynikiem przypadkowym.

Zasada brzmi: przed każdą próbą zmieniasz dokładnie jedną rzecz i zapisujesz wynik, zanim zmienisz kolejną. Zapis ma trzy kolumny: numer próby, co zmieniono, wynik. Wynik opisujesz konkretnie, na przykład „zatrzymał się 8 centymetrów przed linią” zamiast „nie wyszło”, bo liczba pozwala porównać próby między sobą.

Ta tabela jest właściwym wynikiem pracy, nie ozdobą do karty pracy. Dzięki niej po pięciu próbach widzisz, która zmiana dała największą poprawę, i potrafisz wrócić do ustawień z próby trzeciej, jeśli czwarta i piąta okazały się gorsze. Bez tabeli powrót do wcześniejszego ustawienia jest niemożliwy.

Zdarza się, że zmiana jest z natury podwójna, na przykład przebudowa chwytaka zmienia też rozkład ciężaru. Zapisz to wtedy uczciwie jako jedną próbę z dwiema zmianami i licz się z tym, że jej wynik powie Ci mniej.

Gdy robot jedzie krzywo, najpierw sprawdź konstrukcję

Robot dostaje identyczne polecenie na oba silniki, a mimo to skręca. Odruch podpowiada poprawianie programu: zmniejszyć moc jednego silnika, dołożyć korektę kąta. To zwykle strata czasu, bo przyczyna leży w mechanice, a program próbuje ją tylko zamaskować.

Trzy najczęstsze przyczyny mechaniczne to luźno osadzone koło, nierówne rozłożenie ciężaru i tarcie po jednej stronie, na przykład ocierająca się oś albo przewód. Każdą z nich sprawdzisz w kilkanaście sekund: unieś robota i zakręć ręcznie każdym kołem osobno, sprawdzając, czy oba kręcą się równie swobodnie, a potem popchnij robota po stole i zobacz, czy toczy się prosto bez włączonych silników.

Ogólna reguła brzmi: jeśli oba silniki dostają to samo, a robot zachowuje się niesymetrycznie, przyczyna jest fizyczna. Dopiero gdy mechanika jest w porządku, a robot nadal znosi, ma sens korekta mocy w programie. Warto też pamiętać, że poprawa konstrukcji bywa szybszą drogą niż poprawa programu: obniżenie środka ciężkości albo szersze rozstawienie kół potrafi rozwiązać problem, z którym program walczyłby przez pięć prób.

Jeśli nie zdążycie z całą trasą, to nie jest porażka projektu. Dwa etapy działające powtarzalnie i trzy opisane próby są lepszym wynikiem niż jeden przypadkowy przejazd, którego nikt nie umie powtórzyć. Powtarzalność jest tu celem, nie efektowność.