[worklog][Linefollower] SpyEye2

[SanczoPL]

Witam, mam na imię Grzegorz i hobbystycznie interesuje się robotyką. Zrobiłem już wcześniej robota klasy linefollow, mam nadzieje, ze znajdę jakieś stare zdjęcia, aby tu wrzucić, nazywał się EyeSpy. Wcześniejszy robot był sterowany w całości przez układ RaspberryPi i wykorzystywał dedykowaną kamerę. Było to mniej więcej rok temu. Startowałem nim na zawodach w Poznaniu, nie odniosłem wtedy większych sukcesów z wielu różnych powodów. Wcześniej nie bawiłem się w workloga, mam nadzieje, że mi się spodoba.

Zdjęcia pierwszej wersji jeszcze bez Rpi i kamery:

Tutaj robocik bez czujników, z RPi wersja 2:

Po roku odpoczynku od robotów, chciałbym ogłosić, że zebrałem wystarczające fundusze i zaczynam budowę nowego LF i chce poświęcić czas na workloga. Robot będzie podobny do wszystkich innych robotów, więc opiszę go króciutko, skupię się na wymaganiach. W tym projekcie zrobię najpierw kompletnego robota z STM, a później zajmę się dołączeniem Rpi2 itd. Kupiłem już większość części. Między innymi dwa STM (seria L1 20Mhz) i płytkę przejściową do DIP. W planach jest wykonanie systemu sterowania na płytce prototypowej. Całość wykonuje ze znajomym, który to potrzebuje jakiegoś robota do swojej magisterki i będzie mi trochę pomagał. To co zrobiłem do tej pory to pobawiłem się trochę układami STM32 Nucleo i Discovery, napisałem kilka prostych programów, uruchomiłem FreeRTOS. Dodatkowo napisałem wymagania dla jednostki centralnej i chciałbym abyście je sprawdzili, najbardziej krytycznie jak się da.

1. Robot z mikroprocesorem – wymagania:

• Robot będzie niezależny od innych układów,
• Dwa tryby sterowania: automatyczny: przez sygnały sterujące, manualny przez UART bluetooth (BT) lub moduł radiowy,
• RPi2 będzie komunikować się z PC po WiFi,
• Sygnały błędu/sterujące będą używane wyłącznie w trybie automatycznym, przekazywane do uC przez wiele wybranych przez użytkownika interfejsów (SPI,I2C,USART),
• Jednostka centralna będzie miała stałą strukturę, zabezpieczenie od błędów użytkownika, regulator PID, czujniki naładowania baterii, itd.

• Dwa niezależne zasilania, jeden do jednostki centralnej, drugi do zasilania silników i peryferii,
• Kontrola rozładowania baterii silników, każda cela podłączona do ADC, programowe wyłączenie zasilania przy niskim napięciu, poinformowanie użytkownika (3 diody, czerwona-krytyczny poziom baterii, żółta-można ładować, zielona-ok),
• Kontrola stall’u silników – w tym stanie silniki są zatrzymane a płynie przez nie ogromny prąd (zatrzymanie na przeszkodzie) co może je nawet uszkodzić mechanicznie. Dzięki czujnikowi prądu będzie możliwość wykrycia tego stanu i zareagowania + monitoring zużycia prądu,
• Komunikacja po SPI z Rpi2 -wysyłanie statusów odczytów z urządzeń peryferyjnych,
• Wyjścia dodatkowe dla interfejsów np. I2C, SPI – aby móc podłączyć układy zewnętrzne, uC ma dużo pinów, więc będzie sporo dodatkowych złącz z GPIO i interfejsami.

• Enkodery - wykorzystanie do sterowania i zapamiętywania trasy,
• Sterowanie silnikami dzięki 2xPWM i 4xI/O podawanymi na sterowniki silników,
dodatkowe 2 wyjścia na wprowadzenie sterownika w stan niskiego poboru prądu,
• Wysyłanie danych kontrolnych w postaci logów do komputera PC.

Zastanawiam się nad działaniem jednostki sterującej. Myślę, że sygnał sterujący najlepiej jak będzie obsługiwany przez przerwanie i sterowanie PWM będzie odbywało się w obsłudze przerwań. Do tego będzie jeden główny program, który będzie miał za zadanie zrobić wszystko inne. Innym podejściem jest napisanie wątku dla każdej funkcjonalności z odpowiednimi wagami. Jest to rozwiązanie ładniejsze, ale nie wiem do końca, czy będzie działać dobrze, dużą niewiadomą jest komunikacja wątków, wymuszenie korzystania z mutexów. Sądzę, że jeden program w którym funkcjonalności będą odpalane co jakiś ustalony czas liczników będzie lepszy. Program będzie mały więc da się go napisać efektywnie. Rpi2 najszybciej jak się da przetworzy klatkę obrazu i prześle sygnał błędu do jednostki sterującej przez interfejs np. SPI/I2C. Jednostka sterująca w przerwaniu sprawdzi czy jest w odpowiednim trybie i prześle sygnał sterujący do sterownika silników. Gdy sygnał sterujący będzie ustalany co 30Hz to będzie już sukces.

W kolejnym tygodniu zamierzam przylutować układ STM do płytki prototypowej i go uruchomić do migania diody. Dodam dwu/tygodniowe akapity, w których będę opisywał co zrobiłem.

1.09.2015 - 21.09.2015

Mało produktywne wykorzystanie czasu do zadań. Przylutowałem ARM’a do płytki prototypowej, później odlutowałem i przylutowałem ponownie (ostatnia strona się lekko przesunęła). Pomyślałem o wyglądzie i kształcie płytki, mam wstępny pomysł, aby wyglądała tak jak wszystkie inne…

22.09.2015 - 05.10.2015

Zrobiłem bibliotekę do Arma w bibliotece ref-package. Z wcześniejszego schematu płytki wybrałem to co umieszczę w nowym schemacie.

06.10.2015 - 16.11.2015

Niestety nie miałem czasu 🙁

16.11.2015 - 30.11.2015

Wykonałem:

1. Zastanowić się nad rozmieszczeniem pinów i położeniem układu na płytce robota

2. Zrobić pierwsze szkice wyglądu płytki / rozmieszczenie elementów (bateria, rpi, uC)

3. Zrobić schematy połączeniowe do interfejsów – czyli wyjście z pina uC będzie doprowadzone do 3 goldpinów, domyślnie będą to połączone ze sobą zworki, jak będziemy chcieli coś pozmieniać to odłączamy zworkę i wpinamy się do 3 pina. Chodzi o możliwość fizycznego odłączenia pinów od uC i podłączenie zewnętrznego sterowania. To takie wyjście awaryjne, Plan B. W wypadku niepowodzenia z uC nie będzie niepotrzebnego kombinowania, jak się podpiąć do sterowania, będzie gotowe rozwiązanie.

Zadania do wykonania na kolejne 2 tygodnie (do 14 grudznia):

0. Pojawiła się koncepcja aby zrobić wszystko na RPi2, więc poświęcę trochę czasu na sprawdzenie możliwości nowej maliny.

1. Sprawdzić schemat pod kątem ewentualnych błędów.

2. Zamówić drukowanie płytki PCB.

Pozdrawiam 🙂