Tak wyglądają ślady po dzisiejszym berserku pFuda. Podczas jazdy próbnej po zwiększeniu responsywności i niewielkim (naprawdę niewielkim) zwiększeniu zmiennej całkującej w sterowniku PID, pomyślałem, że jazda z odkręconym panelem sterującym i wystającą na kilka centymetrów śrubą w okolicy moich hmm, może mnie zakwalifikować do nagrody Darwina. Podczas odkręcania śruby, robot uznał, że mi pomoże, po czym odpalił jeden silnik na maksimum w przód, a drugi maksimum w tył, dzięki czemu zaczął się obracać przeciwnie do wskazówek zegara z dużą prędkością i obijać oponami o szafę. W tym momencie podziękowałem za pomysł wbudowania wyłącznika. Inaczej czekałoby mnie około 30 - 45 minut obserwowania "robot rampage", bądź próba odkręcenia akumulatora z pędzącego pojazdu. Dobrze, że na tym nie stałem.

Zastanawia mnie, jak to się mogło stać, że bot wpadł w berserk. Jedyna możliwość, to generowanie napięcia na nie podłączonych stykach od kierownicy. Pod znakiem zapytania stawiam możliwość dłuższej jazdy, szczególnie w warunkach "chodnik obok ulicy". Może powinienem zamontować czarną skrzynkę, w której notowane by były stany urządzenia? Może powinienem wprowadzić jakieś dodatkowe zabezpieczenia?

Z perspektywy naukowej, godny odnotowania jest wpływ zwiększenia częstotliwości wykonywania głównej pętli (w tym algorytmu PID) na wyniki. Zgodnie z przewidywaniami, dla różnych częstotliwości należy zmienić wartości zmiennych całkujących i różniczkowych. Z uwagi na dużą wrażliwość szczególnie zmiennej całkującej, przed zmianą częstotliwości należy ją wyzerować. Podczas zwiększania częstotliwości, różniczkowanie staje się mniej czułe, za to różniczkowanie przeciwnie.
Zwiększenie częstotliwości wykonania głównej pętli nie polepszyło szybkości reakcji na przechylenie - bardzo zaskakujące, jeśli wziąć to na zdrowy rozsądek. Również zmienna różniczkująca, czyli pozwalająca reagować na szybkie zmiany, nie dała pożądanych rezultatów, lecz spowodowała przy dużej wartości do niestabilności układu. Dopiero zmienna całkująca poprawiła ten parametr. Jest to kontr intuicyjne i godne dłuższego zastanowienia. Nawarstwianie się niewielkiego błędu w buforze całkowania pozwala na wypoziomowanie podstawy. To by sugerowało, że zmienna proporcjonalna jest wciąż zbyt mała i nie reaguje na niewielkie wychylenia (silniki dostają za mało "mocy", by je niwelować).

Nie masz jakiegoś ogródka czy innego podwórka, żeby to testować?

O ile pFUD będzie dalej żył własnym życiem z narażeniem tegoż parametru u użytkownika, to czarna skrzynka przyda się na zapisanie ,,ostatnich słów''

Na poważniejsze testy wystawiam pFuda na balkon i testuje przy barierce (albo parapecie). Ale musiałbym wgrywać środowisko programistyczne na laptopa, by non stop siedzieć na balkonie i testować wszystko. Wolałem sprzątnąć w pokoju i pousuwać wszystko, co niepotrzebne/na_tyle_drogie_by_tego_żałować.

> czarna skrzynka przyda się na zapisanie ,,ostatnich słów''
Hmmm, proponujesz zamontowanie mikrofonu? Obawiam się, że w takim wypadku ostatnie słowa byłyby albo klnięciem, albo charczeniem. Już wolę na nagrobku "Mamo, Tato! Idę testować pFuda!".

Dlatego nienawidzę sterowników PID. Automatykę szanuję z daleka. Może zaopatrz się w crossowy armorek?

Do tego downhillową zbroję albo motocyklowego żółwia? To nie byłby taki zły pomysł. Ale sterowniki PID fajne są. I to raczej nie ich wina, że czasem coś nie działa tak, jak nie powinno.

Sterowniki PID zjadają małe dzieci.

Powinieneś dorobić sobie zawleczkę jak w sprzęcie ekstremalnym (skutery wodne, motocykle krosowe, itd), która po wypięciu wyłącza sprzęt. To sobie przypnij do siebie i jak coś w sytuacji awaryjnej wystarczy się oddalić

Deadman switch. Jest w konsoli sterowania (tej odłączonej).