Robotyka: Teoria oraz kurs budowy robotów.

Autor: Dondu

Robotyka, to najciekawsza z możliwych dla początkujących dziedzin elektroniki. Łączy w sobie wiele dyscyplin od fizyki, poprzez elektronikę, matematykę, logikę, aż do informatyki.

Ale najważniejsze jest to, że daje wiele satysfakcji w szczególności, gdy pierwszy robot zacznie wykonywać wreszcie to, czego początkujący mechatronik od niego oczekiwał :-)

Robotyka
... i satysfakcja gwarantowana!


Ankiety:

• Ile możesz wydać na elektronikę robota?

Wiedza ogólna:

• Prędkość obrotowa i kierunek obrotu kół
• Linefollower - Listwa czujników linii
• Linefollower - Podążanie za linią

RoDonM8 (linefollower):

• Założenia projektu
• Decyzje wstępne
• Zasilanie modułu głównego - bilans prądów
• Modul główny robota (RoDonM8-MB)  NEW 

RoDonM8 Linefollower: Założenia projektu

Autor: Dondu

Artykuł jest częścią cyklu: Robotyka - Teoria oraz kurs budowy robotów.

Jak zwykle zaczynamy od ustalenia najważniejszych założeń jakie należy poczynić na początku każdego projektu.

Ponieważ projekt dopiero rusza (2013.08.12), to wszyscy czytelnicy mają wpływ na jego efekt końcowy. Dlatego zachęcam do pisania uwag i zadawania pytań w poszczególnych artykułach.


Konstrukcja mechaniczna 

Założenia nasze nie będą dotyczyć części mechanicznej, której rozwiązanie pozostawiam Waszej inwencji.


Założenia nadrzędne

• cel stricte edukacyjny,
• minimalizowanie ilości elementów zewnętrznych,
• minimalizowanie poboru energii,
• minimalizowanie kosztów,
• konstrukcja modułowa w celu łatwiejszej modyfikacji,
• wykonanie części mechanicznej z elementów dostępnych "w szufladach" lub gotowych podwoziach lub z kupionych elementów jeśli ktoś woli :-)

Założenia dot. elektroniki

• konstrukcja oparta o mikrokontroler ATmega8 (patrz wyjaśnienie w dalszej części artykułu),
• projekty płytek PCB dla metody "żelazkowej",
• ... czekam na dalsze propozycje.

Założenia dot. programu

• nie stosowanie funkcji opóźnień programowych i pętli oczekujących,
• stosowanie programowych regulatorów prędkości robota oraz wykrywania i reagowania na przesuwającą się linię,
• używanie wskaźników i struktur,
• opracowanie bibliotek poszczególnych funkcjonalności,
• ... czekam na dalsze propozycje.

Funkcjonalności robota

• podążanie za linią z możliwie największą prędkością, 
• odszukanie linii po wypadnięciu z trasy,
• zapisywanie w czasie jazdy parametrów (prędkość, nastawy silników, stan czujników, itp) do pamięci, w celu ich późniejszej analizy,
• określanie kierunku i prędkości obrotu kół,
• dostosowywanie poziomu oświetlenia czujników linii do jakości podłoża,
• autokalibracja czujników linii,
• reagowanie na komendy wydawane pilotem podczerwieni RC-5,
• kontrola źródła zasilania,
• zapamiętywanie trasy w celu dokonania szybszego drugiego przejazdu (w miarę wolnej pamięci lub jako osobny temat),
• ... czekam na dalsze propozycje.

Funkcjonalności analizy zebranych danych

Funkcjonalności te dotyczą narzędzi, które pomogą nam analizować pozyskane wyniki pomiarów w celu modyfikacji algorytmów zachowań robota. W tym zakresie należy opracować:

• format zapisu danych do pamięci,
• funkcjonalności bloga (niniejszej strony) w zakresie automatyzacji generowania tabel i wykresów na podstawie przesłanych danych.

Dodatkowe urządzenia pomiarowe

W celu testowania i maksymalizowania osiągów, w ramach niniejszego cyklu wykonamy w dalszej kolejności:

• hamownię silników,
• bramki pomiaru czasu przejazdu,
• własny pilot podczerwieni RC-5 (o ile będzie takie zapotrzebowanie),
• ... czekam na dalsze propozycje.

Dlaczego ATmega8?

Uprzedzając ewentualne pytania wyjaśniam, że ATmega8 to świadomy i celowy wybór ze względu na to, iż ten mikrokontroler stosujemy w przypadku artykułów dla początkujących. Dlatego też naturalnym jest iż pierwszy robot, będzie oparty o ten właśnie mikrokontroler.

Drugim powodem i celem jest pokazanie, jak w przypadku ograniczonych możliwości sprzętowych (tego mikrokontrolera) kombinować w celu osiągnięcia założonych celów.



Kolejne roboty na XMega

Drugim robotem prezentowanym w tym cyklu artykułów będzie RoDonXM, czyli konstrukcja oparta o znacznie bardziej zaawansowany mikrokontroler, którym będzie jeden z rodziny XMega. W tym robocie położymy szczególnie nacisk na zwiększanie osiągów pokazując jednocześnie kierunki i możliwości modyfikacji.

Jeżeli cykl dot. robotów będzie się cieszył dużym zainteresowaniem, to zajmiemy się kolejnymi, nie tylko linefollower-ami.



Propozycje i pytania

Jeżeli masz propozycje lub uwagi dot. założeń to zapraszam do dyskusji w komentarzach do niniejszego artykułu.

RoDonM8 Linefollower: Decyzje wstępne

Autor: Dondu

Artykuł jest częścią cyklu: Robotyka - Teoria oraz kurs budowy robotów.

W poprzednim artykule określiliśmy ogólne założenia dot. robota RoDonM8, nadszedł więc czas na wstępne rozplanowanie dostępnych funkcjonalności mikrokontrolera do zadań stawianych przed robotem.

W każdym z poniższych punktów wyjaśniam każdą podejmowaną decyzję oraz wykazuję niezbędne piny i peryferia, które są potrzebne do realizacji danego zadania. Nieliczne przypadki pozostawiam, do rozstrzygnięcia w dalszej części projektowania robota.


Zaczniemy od:

Częstotliwość taktowania mikrokontrolera

Nasz robot będzie miał sporo zadań do realizacji, a większość z nich będzie niezwykle istotne dla poprawności działania i osiągów robota. Dlatego też powinniśmy na początek przyjąć, że mikrokontroler powinien pracować z możliwie największą częstotliwością zegara taktującego.

Jako, że w założeniach ustaliliśmy, że mikrokontrolerem tym będzie jeden z rodziny Atmega8, to zerkając do datasheet ustalamy, że graniczną częstotliwością taktowania jest 16MHz:

i jest ona osiągalna, ale tylko i wyłącznie przy zastosowaniu zewnętrznego zewnętrznego jego źródła, którym w naszym przypadku będzie rezonator kwarcowy. Kwarc do mikrokontrolera ATmega8 podłącza się do pinów XTAL1 i XTAL2:

Niezbędne peryferia:

• piny XTAL1 oraz XTAL2

---

Wersja mikrokontrolera

W zakresie wersji mikrokontrolera ATmega8 mamy kilka elementów do rozpatrzenia:


Obudowa

Ze względu na fakt, iż wykorzystamy sporo (a może nawet wszystkie) piny mikrokontrolera Atmega8, należy przyglądnąć się jego różnym wersjom obudowy. Interesować nas będą tylko te, które łatwo można lutować:

Zauważ, że w przypadku ATmega8 w obudowie TQFP mamy więcej pinów niż w obudowie DIP. Konkretnie jest ich o cztery więcej i są nimi:

• jeden pin Vcc,
• jeden pin GND,
• dwa piny przetwornika ADC (ADC6 i ADC7).

O ile dodatkowe piny zasilania nie mają dla nas żadnego znaczenia (choć oczywiście je podłączymy zgodnie z zasadami prawidłowego zasilania mikrokontrolerów), o tyle dwa dodatkowe kanały przetwornika ADC są dla nas bardzo pożyteczną cechą obudowy TQFP, która znacznie ułatwi nam realizację robota.

Dlatego też, do naszego robota wykorzystamy wersję w obudowie TQFP. Tych co obawiają się lutowania takiego układu pragnę pocieszyć, że jest to naprawdę prosta czynność, ponieważ raster (czyli odstępy między środkami sąsiednich nóżek) jest spory i wynosi 0,8mm co oznacza, że przy szerokości nóżki 0,3mm odstępy między krawędziami sąsiednich nóżek wynosi 0,5mm.

To jest bardzo przyjemny w lutowaniu raster, który spokojnie przylutujesz nawet lutownicą transformatorową, używając dużej ilości kalafonii. Także wykonanie płytki pod raster 0,8mm „metodą żelazkową” (powszechną wśród hobbystów) jest możliwe i nie powinno być z tym kłopotów.


Wersja mikrokontrolera

Mikrokontroler ATmega8 produkowany jest w 3 wersjach:

• Atmega8,
• Atmega8L,
• Atmega8A.

Częstotliwość taktowania

Ponieważ ustaliliśmy, że mikrokontroler będzie pracował z najwyższą możliwą częstotliwością zegara taktującego, to zerkamy do datasheet szukając informacji pod kątem maksymalnych częstotliwości wybranych wersji, gdzie już na pierwszej stronie znajdujemy:

Atmega8 i Atmega8L:

Atmega8 i Atmega8L

Atmega8A:

Atmega8A

Jak widać wersja Atmega8L odpada ponieważ może pracować tylko z częstotliwością do 8MHz.
Pozostają nam więc do wyboru wersje ATmega8 i ATmega8A.


Napięcie zasilania

Zapewne zauważyłeś powyżej, że ATmega8 nie może pracować z napięciami niższymi niż 4,5V. Mogłeś także stwierdzić, że ATmega8A może pracować z częstotliwością od 0 do 16MHz, w pełnym zakresie napięć od 2,7 do 5,5V. Niestety tak nie jest, a pokazuje to wykres bezpiecznego obszaru pracy:

Atmega8A

na którym widać, że ATmega8A, by pracować z wymaganą przez nas częstotliwością 16MHz także wymaga co najmniej 4,5V.


Prąd w czasie pracy

Ponieważ nasz RoDonM8 będzie zasilany z akumulatorów lub baterii, stąd należy w miarę możliwości minimalizować pobór prądu, na wszystkich etapach jego projektowania. Dlatego też zerkamy do datasheet pozostałych na placu boju mikrokontrolerów w poszukiwaniu odpowiednich danych.

Dla Atmega8 znajdujemy:

Atmega8

i ustalamy, że Atmega8 podczas pracy z zegarem 16MHz przy zasilaniu 5V zużywać będzie około 20mA.

W przypadku Atmega8A:

Atmega8A

na wykresie ustalamy, że przy tej samej częstotliwości taktowania pobór prądu będzie w okolicach 11mA, czyli prawie o połowę mniejszy niż Atmega8. Stąd nasz wybór powinien paść na ATmega8A.


Podsumowanie

Najlepszą dla potrzeb RoDonM8 jest wersja Atmega8A w obudowie TQFP. W ostateczności możemy użyć wersji Atmega8, ale nie możemy użyć Atmega8L, gdyż nie pracuje z zegarem 16MHz.

---

Sterowanie silników

Do sterowania silników użyjemy scalonego sterownika silników lub wykonamy własny na tranzystorach MOSFET. Niezależnie od tego niezbędne będą nam dla każdego silnika:

• kanał PWM do sterowania prędkością obrotów,
• pin sterujący kierunkiem obrotów silnika.

Dobrze byłoby także wiedzieć jaki prąd pobiera każdy silnik, aby w pełni kontrolować jego parametry pracy oraz zabezpieczyć silniki przed uszkodzeniem. Potrzebne więc nam będzie na każdy silnik dodatkowo:

• wejście przetwornika analogowo-cyfrowego.

W rezultacie otrzymamy następujący schemat blokowy:

Niezbędne peryferia:

• timer z dwoma wyjściami PWM (w ATmega8 jest to Timer1),
• dwa piny sygnałów PWM,
• dwa piny sterujące kierunkiem obrotu silników,
• dwa wejścia przetwornika ADC do pomiaru prądów silników.

---

Pomiary prędkość oraz kierunku obrotu kół

Wiedza o aktualnym kierunku i prędkości obrotu kół jest jednym z najistotniejszych elementów Linefollowera jak i innych robotów poruszających się za pomocą kół, co opisałem w osobnym artykule:
Robotyka: Teoria - Prędkość obrotowa i kierunek obrotu kół

Wyjaśniłem tam, dlaczego musimy określać dla każdego koła faktyczne:

• prędkość obrotów,
• kierunek obrotów.

Wytłumaczyłem tam także dlaczego potrzebować będziemy, aż dwa czujniki na jedno koło, czyli w przypadku naszego RoDonM8 będą to łącznie cztery czujniki.

Z punktu widzenia programu, by dokładnie mierzyć prędkości obrotowe kół niezbędne jest dokładne wyznaczanie momentu, w którym czujnik wiodący trafia na np. czarne pole tarczy impulsatora. Aby ten moment uchwycić w miarę możliwości bez opóźnień, można wykorzystać przerwania zewnętrzne. W mikrokontrolerze ATmega8 mamy do dyspozycji piny INT0 oraz INT1 i wykorzystamy je podłączając do czujnika wiodącego enkdera.

W związku z tym nasz układ pomiaru prędkości i kierunku obrotu koła wyglądać będzie następująco:

Do pomiaru prędkości będzie nam potrzebny timer, który będzie zliczał czas upływający pomiędzy kolejnymi impulsami.

Reasumując, w ten sposób będziemy mogli zmierzyć aktualną prędkość obrotową oraz kierunek obrotu kół.

Niezbędne peryferia:

• dwa piny przerwań zewnętrznych z możliwością ustawienia wybranego zbocza sygnału dla transoptorów wiodących (INT0 oraz INT1),
• dwa piny dla transoptorów kierunku,
• timer.

---

Czujniki linii

Jako czujniki linii wykorzystamy transoptory odbiciowe, które będą w stanie „widzieć” linię na tle pozostałej powierzchni, po której jedzie robot. Wybór konkretnych transoptorów zostawiamy na później, teraz ustalamy jedynie sposób realizacji tej funkcjonalności robota i wymagane piny.

Ponieważ sygnał z transoptorów jest sygnałem analogowym należy wybrać pomiędzy dwoma rozwiązaniami podłączenia ich do mikrokontrolera:

1. transoptory podłączone do zewnętrznych komparatorów,
2. transoptory podłączone do wejść analogowych przetwornika ADC mikrokontrolera.

co szczegółowo opisałem w artykule: Linefollower - Podążanie za linią

Ponieważ jednym z nadrzędnych założeń RoDonM8 jest minimalizacja kosztów oraz wagi, a także samo-kalibracja, stąd ustalamy, że wykorzystamy sposób drugi, czyli przetwornik ADC.

Zgodnie z założeniami RoDonM8 wykorzystujemy mikrokontroler ATmega8A, który ma zaledwie maksymalnie 8 kanałów ADC. Ponieważ powyżej ustaliliśmy, że dwa kanały musimy wykorzystać do pomiaru prądu silników, stąd dla potrzeb czujników pozostanie nam maksymalnie 6 kanałów. To trochę mało o czym pisałem w temacie dot. listwy czujników.

Dodatkowo na tym etapie nie wiemy jeszcze ile w ogóle pinów nam zostanie. Dlatego decyzję w zakresie ilości czujników linii podejmiemy później, po ustaleniu niezbędnych pinów dla pozostałych funkcjonalności robota, co determinuje ilość pinów ADC, które pozostaną do naszej dyspozycji.Jeżeli pozostanie nam mało wejść ADC powinniśmy się zastanowić, jak powiększyć ich ilość.

Niezbędne peryferia:

• piny ADC w ilości uzgodnionej w późniejszym czasie,
• pin AREF z kondenstarorem,
• pin AVcc z filtracją dobrą zasilania.

---

Pilot RC-5

Każdy robot powinien mieć możliwość reagowania na wydawane przez właściciela komendy. Mam tutaj na myśli przygotowanie robota do wykonania zadania poprzez wybór jakiejś opcji algorytmu, czy innych nastaw, które przed wyruszeniem na trasę należy ustawić.

Poza tym przy bardzo szybkim robocie istotnym jest posiadanie możliwości jego zdalnego zatrzymania na końcu trasy lub gdy z niej wypadnie poza planszę.

Dlatego też podejmujemy decyzję, że zastosujemy pilot podczerwieni w standardzie RC-5. Do odbioru sygnału RC-5 potrzebować będziemy:

• najprostszy timer 8-bit,
• pin przerwania zewnętrznego.

Timer możemy współdzielić z którąś z innych funkcjonalności robota, ponieważ komendy będą wydawane tylko w czasie jego postoju lub chęci zatrzymania.

W przypadku pinu przerwania nie mamy już takiego komfortu. Problem polega na tym, że mikrokontroler ATmega8 ma tylko dwa piny przerwań zewnętrznych, którymi są INT0 oraz INT1, a te już zarezerwowaliśmy dla określania prędkości i kierunku obrotu kół. Rodzina Atmega8 nie ma także możliwości generowania przerwań ze zmiany stanu innych pinów cyfrowych (ang. pin change interrupt).

Musimy więc poszukać innej możliwości, a jest nią wykorzystanie wbudowanego komparatora analogowego, którego nie będziemy wykorzystywać do innych celów:

W ten sposób będziemy mogli skutecznie wyłapywać zbocza sygnału RC-5 i odbierać komendy z pilota podczerwieni.

Niezbędne peryferia:

• dwa piny komparatora,
• komparator z przerwaniem,
• timer (może być współdzielony z inną funkcjonalnością).

---

Zapamiętywanie parametrów jazdy

Jednym z naszych założeń, jest zapamiętywanie parametrów w czasie pracy robota. Rodzaj danych ustalimy w późniejszym czasie, ale na pewno będą to co najmniej:

• prędkość obrotowa kół,
• kierunek obrotu kół,
• nastawione prędkości kół,
• stan czujników,
• podejmowane decyzje,
• itp.

W tym celu niezbędna jest dodatkowa pamięć ponieważ w Atmega8, który jest podstawą RoDonM8, nie mamy wystarczających zasobów pamięci SRAM, ani EEPROM. Możemy rozpatrzyć więc dwie możliwości:

1. karta pamięci SD,
2. zewnętrzna pamięć EEPROM lub SRAM o sporej pojemności.

Karta pamięci SD 

Karta pamięci SD (w szczególności microSD) jest fajnym rozwiązaniem ze względu na:

• olbrzymią pojemność i swobodę ustalenia formatu danych (dane w formie binarnej lub tekstowej),
• poręczność w zakresie wyciągnięcia z robota i odczytu w komputerze, co zaoszczędziło by nam piny do komunikacji z komputerem w celu odczytu danych.

Jednakże w naszym przypadku zastosowanie karty SD znacznie zmniejszy poziom dostępnej pamięci programu i z tego powodu rozwiązanie to jest dla nas niemożliwe do zaakceptowania. Dodatkowo karta SD pobiera znaczne ilości prądu, a chcemy minimalizować ten parametr, ze względu na źródło zasilania (akumulator, bateria) i jego ciężar.

Pozostaje nam więc zastosowanie zewnętrznej pamięci EEPROM lub SRAM.


Który interfejs do komunikacji?

Zanim wybierzemy rodzaj pamięci powinniśmy ustalić, który interfejs dostępny w ATmega8 wykorzystamy do komunikacji z pamięcią. Mamy do wyboru:

• TWI (czyli I²C),
• SPI.

Zaglądamy więc do datasheet ATmega8 i znajdujemy tabelkę:

Aby wykorzystać interfejs TWI musielibyśmy poświęcić dwa piny portu C, na których zlokalizowane są także wejścia przetwornika ADC. Ponieważ podjęliśmy decyzję, że czujniki będziemy odczytywać, za pomocą ADC, nie możemy więc poświęcać jego pinów na inne funkcjonalności. Z tego powodu interfejs TWI odpada.

Nie mamy więc wyboru i musimy zastosować interfejs SPI.

Mamy z tego tytułu dodatkowe zyski:

• wykorzystamy te same piny co złącze programowania (MOSI, MISO i SCK),
• znacznie szybsze przesyłanie danych z częstotliwością linii SCK nawet 8MHz przy kwarcu 16MHz. Dla porównania interfejs TWI pozwalałby na maksymalnie 0,4MHz.

Ale będą tekże straty:

• pamięć z interfejsem SPI wymaga dodatkowego pinu sterującego CS.

Zysk dot. współdzielenia pinów jest oczywisty i bardzo pożądany, o tyle dodatkowy pin sterujący pamięcią może być dla nas problemem, którego ewentualne rozwiązanie zostawimy sobie na później.


Pamięć EEPROM

Pamięci EEPROM mają tę zaletę, że po odłączeniu zasilania zapisane dane nie są tracone. Mają jednak istotną dla nas wadę, którą jest długi czas zapisu danych. Popatrzmy na popularną pamięć serii 24Cxx, a konkretnie na AT24C32 i AT24C64:

Pięć milisekund to sporo czasu. Wprawdzie pamięć ta zorganizowana jest w 32-bajtowe strony, co pozwala zwiększyć szybkość zapisu bloku danych, to nadal zapis takiego bloku trwa 5ms.

Czy taki czas zapisu nie jest dla nas zbyt długi?

Policzmy:

Ilość 200-tu pomiarów po 32 bajty, to sporo informacji i być może wystarczy do naszych celów:

Pamięć SRAM

Jednakże znając nasz apetyt na analizę zebranych danych, wielkość transferu na poziomie 6,25kB/s (kBps) to porcja informacji, która może być zbyt mała, jeżeli będziemy chcieli zapisywać także dane o trasie lub inne parametry.

W takim przypadku warto przyglądnąć się pamięciom SRAM, które zapisują dane bez dodatkowego zauważalnego czasu zapisu, czyli natychmiast po otrzymaniu danych (ang. Zero Write Time).

Wprawdzie nie są one odporne na zanik zasilania, ale dla nas nie jest to problemem, ponieważ po zatrzymaniu robot przejdzie do stanu czuwania, czyli będzie podtrzymywał stan pamięci, aż do odłączenia akumulatora. Aby zabezpieczyć się przed zapominalskim, czy podekscytowanym twórcą, możemy przypominać o konieczności odczytu danych, na przykład za pomocą świecącej, czy migającej diody.


Wielkość pamięci

Pamięci SRAM nie są drogie, ale też i nie są tanie. Dlatego poświęcę, chwilkę na ten temat.

Ponieważ na ten moment, nie jak duże będzie zapotrzebowanie na pamięć, to rozważmy wyżej obliczony transfer oraz maksymalny czas jazdy robota, który przyjmiemy na poziomie 15 sekund:

Pamięć jaka potrzebna byłaby do takiego pakietu danych, to pamięć 128kB na przykład 23LCV1024, która kosztuje około 11-12zł (cena 2013r.).

Nie jest to mało zważywszy cenę mikrokontrolera ATmega8 na poziomie około 5zł. Jednakże uważam, że posiadanie tak dużej pamięci jest zasadne i da nam możliwość gromadzenia sporej ilości danych do późniejszej analizy, w celu "śrubowania" osiągów robota do granic jego możliwości.

Można oczywiście będzie wstawić inną tańszą pamięć o mniejszej pojemności, ponieważ biblioteki, które utworzymy będą przygotowane do takiej zamiany. Można także w ogóle zrezygnować z tego modułu i zaoszczędzić trochę pieniędzy, kosztem braku danych do analizy.


Napięcie zasilania

Przy wyborze pamięci należy w szczególności zwrócić uwagę, na dopuszczalne napięcia jej pracy.

Tutaj możesz spotkać wiele różnych zakresów. W naszym przypadku ustaliliśmy już, że napięciem zasilającym elektronikę robota, będzie 5V. Dlatego też warto wybrać taką pamięć, która będzie mogła pracować z tym napięciem, by nie trzeba było stosować dodatkowych układów dostosowujących poziomy sygnałów sterujących oraz dodatkowego problemu związanego z zasilaniem takiej pamięci.


Podsumowując

Wykorzystując pamięć SRAM wraz z interfejsem SPI, będziemy mieli bardzo wydajny moduł zapisu danych w trakcie pracy robota. Od nas będzie tylko zależało, w jaki sposób wykorzystamy ten moduł.

Niezbędne peryferia:

• współdzielenie pinów MOSI, MISO i SCK,
• dodatkowy pin do obsługi pinu CS pamięci,
• interfejs SPI.

---

Komunikacja z komputerem

Aby odczytać zgromadzone w pamięci SRAM dane z jazdy robota, musimy dysponować interfejsem do komunikacji z komputerem. Warto byłoby także mieć możliwość wysłania do mikrokontrolera jakiś danych, np. jakiejś obszerniejszej tablicy danych konfigurujących robota.

Tanią możliwością jest wykorzystanie interfejsu RS-232, do którego dostęp powinien mieć każdy, kto zajmuje się mikrokontrolerami (np. za pomocą konwertera RS232-USB). Interfejs ten wykorzystuje piny RxD oraz TxD, a komunikację oprzemy oczywiście o przerwania na bazie artykułu: RS-232: Komunikacja ATmega8 z komputerem

Niezbędne peryferia:

• piny TxD oraz RxD,
• interfejs USART.

Robotyka: Teoria - Prędkość obrotowa i kierunek obrotu kół

Autor: Dondu

Artykuł jest częścią cyklu: Robotyka - Teoria oraz kurs budowy robotów.

Wiedza o aktualnym kierunku i prędkości obrotu kół jest jednym z najistotniejszych elementów robotów poruszających się za pomocą kół.

Dlaczego?

Rozważmy następujące problemy:

1. Prędkość obrotowa kół

Prędkość obrotową kół robota ustawia się poprzez odpowiednie ustawienie wypełnienia sygnału PWM sterującego silnikami:

W dużym uproszczeniu dla potrzeb niniejszego artykułu przyjmujemy, że:

Uproszczenie modelu
dla potrzeb niniejszego artykułu.

prędkość obrotowa jest zależna liniowo od wartości wypełnienia sygnału PWM.


Nastawienie zadanej prędkości obrotowej poprzez odpowiednie ustawienie wypełnienia sygnału PWM nie oznacza jednak, że robot natychmiast rozpędzi koła do tej prędkości. Jest to niemożliwe przede wszystkim z powodu ograniczonego momentu obrotowego silników oraz niezerowej masy robota, a także innych sił (nazwijmy je roboczo "spowalniaczami"):

• bezwładność wirnika silnika i kół, 
• tarcie o podłoże, 
• uginanie opon, 
• straty na przekładniach, 
• opór powietrza,
• itd. 

Wszystkie wyżej wypunktowane "spowalniacze" zawrzeć można w jednej wypadkowej sile FS.

Przyspieszenie robota jest więc zależne od przyspieszenia prędkości obrotowej kół, które przekładają moment obrotowy generowany przez silnik na siłę F działającą na robota, pomniejszoną o sumaryczną siłę "spowalniaczy" (FS).

Siłę wypadkową FW działającą na robota można więc zapisać następująco:

Skoro wiemy już, że przyspieszenie robota zależy od wypadkowej siły działającej na robota oraz od jego masy, możemy więc stwierdzić, że przyspieszenie naszego robota obliczymy następująco:

gdzie:

• a - przyspieszenie robota
• Fw - wypadkowa siła działająca na robota
• m - masa robota

Jest to nic innego jak:

II zasada dynamiki Newtona
Jeśli siły działające na ciało nie równoważą się, to ciało porusza się ruchem przyspieszonym (opóźnionym), w którym przyspieszenie (opóźnienie) jest wprost proporcjonalne do wartości siły wypadkowej, a odwrotnie proporcjonalne do masy tego ciała.

Możemy więc wyciągnąć pierwszy wniosek, że:

Przy tych samych silnikach i przekładniach oraz innych "spowalniaczach", im większa masa robota tym przyspieszenie będzie mniejsze.

Skoro przyspieszenie jest zależne od wypadkowej siły działającej na robota (której wielkość jest przecież ograniczona momentem obrotowym i "spowalniaczami") oraz masy robota (która nie jest zerowa), to możemy się domyślić, że:

Od momentu zadania nowej prędkości obrotowej do momentu jej osiągnięcia, upływa pewien czas.

Pewien czas ... , ale jak długi?

Tutaj z pomocą przychodzi nam:

Ogólna definicja przyspieszenia
Przyspieszenie, to wielkość fizyczna wyrażająca zmianę prędkości w czasie.

Możemy więc zapisać nasze przyspieszenie jako:

gdzie:

• Δv - zmiana prędkości,
• Δt - czas trwania zmiany prędkości.

Przyrównując oba powyższe wzory przyspieszenia stronami możemy zapisać, że:

Ponieważ nas interesuje czas, stąd po przekształceniu otrzymujemy:

co rozumiemy następująco:

Czas zmiany prędkości zależy wprost proporcjonalnie od wielkości zmiany prędkości oraz masy robota, a odwrotnie proporcjonalnie od siły działającej na robota.

Podsumowując, od momentu zadania nowej wartości PWM, do momentu osiągnięcia nastawionej prędkości obrotowej kół robota upływa określony czas, który jest zależny od wielu w/w czynników.

Podobnie jest w przypadku zmniejszenia nastawionej prędkości, ze względu na siłę bezwładności robota, która nie pozwoli na natychmiastowe zmniejszenie prędkości do prędkości zadanej i musi upłynąć jakiś czas zanim faktyczna prędkość obrotowa będzie równa prędkości zadanej.


Ruszanie z miejsca

Ruszanie z miejsca, to specyficzny moment przyspieszania.

To zjawisko łatwo jest doświadczyć na własnej skórze. Wystarczy spróbować pchać własnoręcznie samochód. Zauważysz wtedy, że najgorszym momentem jest ruszenie samochodu z miejsca. Jest to związane z faktem, iż musimy przezwyciężyć wiele sił i oporów (zwane wcześniej "spowalniaczami") oraz nadać samochodowi pewną niezerową prędkość, czyli przyspieszyć. Następnie, gdy już osiągniesz zadaną prędkość do jej utrzymania wystarczy znacznie mniejsza siła.

W przypadku robotów zjawisko to oczywiście także występuje, choć siły są znacznie mniejsze (no chyba że robotem jest samochód). Dlatego też w czasie ruszania z miejsca w szczególności następuje moment, w którym prędkość obrotu kół nie odpowiada prędkości zadanej.


Powierzchnia pochyła

Roboty nie jeżdżą tylko i wyłącznie po powierzchniach płaskich, stąd zapewne jesteś świadomy, że na powierzchniach pochyłych w zależności od tego, czy robot jedzie pod górę, czy w dół, czas niezbędny do osiągnięcia zadanej prędkości obrotowej kół będzie:

• dłuższy, gdy robot jedzie pod górę,
• krótszy, gdy jedzie w dół.

Równia pochyła
Źródło: Wikipedia

Istnieje też możliwość, że z powodu zbyt dużej pochyłości powierzchni, robot nie będzie w stanie osiągnąć zadanej prędkości obrotowej kół.


Zatrzymanie na równi pochyłej

Aby zatrzymać robota na równi pochyłej w przypadku braku hamulców niezbędne jest:

1. ustawienie robota bokiem, tak by nie zjeżdżał z górki pod wpływem siły grawitacji,
2. lub generowanie przez silniki siły, równoważącej siłę grawitacji spychającą robota w dół.

Ten drugi przypadek jest dla nas najlepszym przykładem dlaczego nie możemy ufać jedynie zadanej wartości prędkości obrotowej poprzez odpowiednie wypełnienie sygnału PWM.

W przypadku tym ustawienie niezerowego wypełnienia sygnału PWM, świadczyłoby o tym, że pojazd porusza się, podczas gdy faktycznie jedynie stałby w miejscu na równi pochyłej, czyli koła nie kręciły by się.

Buksowanie kół i poślizg w czasie hamowania

W powyższych rozważaniach nie bierzemy pod uwagę istotnego zjawiska jakim jest buksowanie kół. Zjawisko to występuje wtedy, gdy koła nie mają wystarczająco dużej przyczepność do podłoża i zaczynają się obracać szybciej niż następuje przemieszczenie liniowe robota wynikające z obwodu koła.

Innymi słowy silniki mają tak duży moment obrotowy, że zrywają przyczepność kół do podłoża powodując szybkie przyspieszenie prędkości obrotowej kół, przy jednocześnie niewielkiej zmianie prędkości liniowej robota.

Specyficznym przypadkiem buksowania jest moment hamowania, w którym następuje zjawisko buksowania lecz niejako w drugą stronę. Jeżeli siła tarcia koła o powierzchnię nie jest wystarczająco duża, to następuje poślizg kół, a wartość zadana prędkości obrotowej, nie odpowiada faktycznej.

Jeszcze innym przypadkiem jest uślizg kół na zakrętach, przy zbyt małej przyczepności w stosunku do promienia skrętu i prędkości robota. W tym wypadku koła także będą się kręcić z inną prędkością niż zadana.

Z naszego punktu widzenia, zjawiska te są bardzo niekorzystne nie tylko z powodu mniejszego przyspieszenia, czy hamowania robota, ale przede wszystkim z błędnych wniosków wyciąganych przez algorytm robota jedynie na podstawie zadanej prędkości obrotu kół.



Wniosek końcowy nr 1

Wyciągamy więc najważniejszy dla nas wniosek z tego punktu:

Nigdy nie możemy przyjmować, że zadana prędkość obrotowa kół jest równa faktycznej prędkości obrotowej.

---

2. Kierunek obrotu kół


Koła robota z reguły są na sztywno sprzężone z silnikami bezpośrednio lub poprzez przekładnie.W związku z tym w momencie, gdy ustawimy na przykład jazdę do przodu powinniśmy się spodziewać, że koła kręcą się w tym kierunku. Jednakże nie jest to takie oczywiste!

Rozważmy następujące przypadki:

Jazda pod górkę

Podczas jazdy pod górę może się okazać, że przy zadanym nastawieniu PWM, silniki nie generują wystarczającego momentu obrotowego, by robot pod górę był w stanie jechać.

Może się więc okazać, że pomimo nastawienia jazdy do przodu, robot porusza się do tyłu.

Hamowanie przez odwrócenie kierunku obrotów

Podobnie dzieje się, gdy rozpędzonego robota próbujemy hamować za pomocą odwrócenia ciągu, czyli ustawienia obrotów w przeciwnym kierunku. W takiej sytuacji jeżeli nie zerwiemy przyczepności kół do podłoża, będziemy spotykali się z sytuacją, że robot jedzie jeszcze jakiś czas (siłą bezwładności) np. do przodu, pomimo że ustawiliśmy jazdę do tyłu.


Zderzenie z ciałem obcym

Jeszcze innym przypadkiem, w którym możemy zaobserwować problem innego kierunku obrotu kół niż kierunek zadany, jest zderzenie z ciałem obcym. Innymi słowy, gdy w naszego robota jadącego do przodu uderzy czołowo na przykład inny robot o zgromadzonej znacznie większej energii, to nasz robot zacznie jechać do tyłu pomimo, że ma zadany tryb jazdy do przodu.



Wniosek końcowy nr 2

Wyciągamy więc najważniejszy dla nas wniosek z tego punktu:

Nigdy nie możemy przyjmować, że zadany kierunek obrotu kół kół jest faktycznym kierunkiem.

---

3. Jazda po prostej

Niemniej istotnym jest fakt, iż mechaniczny układ jezdny nie jest idealny. Oznacza to, że:

Przy tych samych nastawach prędkości obrotowej kół prawego i lewego (sygnały PWM) mogą występować różnice w faktycznej prędkości liniowej lewego i prawego boku robota.

Jaki będzie tego skutek?
Robot nie będzie poruszał się po linii prostej lecz skręcał na przykład tak:

Aby sobie z tym problemem poradzić należy znać prędkości obrotowe kół oraz współczynnik różnicy pomiędzy kołami lewej i prawej strony robota, który można wyznaczyć doświadczalnie, a co łącznie pozwoli nam na jazdę po linii zbliżonej do prostej.

---

Wnioski główne

Podsumowując niniejszy artykuł:

Aby móc panować nad robotem nie możemy ufać wartościom zadanym (prędkości i kierunkowi) lecz musimy określać dla każdego koła osobno faktyczne:

• prędkość obrotów,
• kierunek obrotów.

W tym celu potrzebne nam będą czujniki, którymi mogą być transoptory odbiciowe lub szczelinowe. Możemy także wykorzystać czujniki Halla, ale jest to trudniejsze w realizacji od strony mechanicznej, dlatego my zastosujemy transoptory.

Aby zmierzyć prędkość obrotów koła, wystarczy jeden czujnik i odpowiednia tarcza impulsatora:

Jednakże, by wykryć kierunek obrotu koła niezbędne są dwa czujniki, a działanie ich jest oparte o tę samą zasadę, co działanie impulsatora (enkodera). W tym przypadku musimy więc tak rozmieścić czujniki, by dawały sygnały przesunięte w fazie względem siebie:

Stąd oba czujniki jednego koła powinny być rozmieszczone względem tarczy impulsatora następująco:

W ten sposób będziemy mogli zmierzyć zarówno aktualną prędkość obrotu kół, jak i określić kierunek ich obrotu, co pozwoli nam na wyeliminowanie prawie wszystkich wyżej wymienionych problemów.

Robotyka: Linefollower - Podążanie za linią

Autor: Dondu

Artykuł jest częścią cyklu: Robotyka - Teoria oraz kurs budowy robotów.

Roboty jeżdżące po wyznaczonej trasie narysowanej na podłożu lub z nim zintegrowanej, nie są bynajmniej nowością. Są one powszechnie wykorzystywane od wielu lat w zautomatyzowanych fabrykach, w czym przodowali oczywiście Japończycy w latach 70-tych i 80-tych XX wieku.

Techniki wyznaczenia drogi były różne od narysowanych linii w fabrykach, w których czystość była możliwa do zachowania idealnej czystości, do elektromagnetycznych tam gdzie takiego warunku nie można było spełnić.

Jedna cecha była wspólna - czujniki wykrywały drogę ciągle ją obserwując:

Magazyn SONDA - rok 1983

Andrzej Kurek, Zdzisław Kamiński i Tomasz Pyć

... którzy rozbudzali moją ciekawość fizyki, elektroniki i informatyki.
Dziękuję Wam i szkoda, że nie ma już Was wśród nas ...

Aktualnie odbywa się to tak (np. Amazon w 2013r.):



W przypadku naszego robota niezbędne będą:

• podłoże z linią w kolorze kontrastowym do podłoża,
• robot z czujnikiem optycznym,
• algorytm podążania za linią.

W niniejszym artykule zajmiemy się częścią elektroniczną czujników linii. Jako czujniki linii można wykorzystać:

• kamerę wideo,
• inne elementy światłoczułe,

a w obu przypadkach, do rozpoznania linii niezbędne jest źródło światła. W przypadku tego artykułu interesuje nas ta druga grupa, czyli czujniki światła odbitego.

Jako czujniki światła odbitego, wykorzystywane w procesie śledzenia linii przez małe roboty (linefollowery) , wykorzystywane są z reguły scalone transoptory odbiciowe.

Zawierają one w sobie zarówno, źródło światła (emiter) jak i element światłoczuły (detektor):

Transoptor odbiciowy CNY70.

Transoptor odbiciowy KTIR0711S.

Symbolem prostego transoptora odbiciowego jest podstawowy symbol transoptora:

Symbol transoptora odbiciowego.

Noty katalogowe (datasheet) powyższych transoptorów:

• CNY70,
• KTIR0711S.

Aby łatwiej zrozumieć zagadnienia poruszane w niniejszym artykule, powinieneś znać dokładnie najistotniejsze parametry transoptorów odbiciowych, które opisałem w cyklu: Transoptory odbiciowe

---

Sygnał cyfrowy, czy analogowy?

Na początek postawmy pytanie: Jaki rodzaj sygnału dostarcza transoptor odbiciowy?

Dla nas najlepiej byłoby, gdyby transoptor dostarczał od razu sygnał cyfrowy w postaci np.:

• gdy czujnik jest nad linią, to otrzymujemy jedynkę,
• gdy czujnik jest poza linią, otrzymujemy zero.

Czy to jest możliwe?
Niezupełnie ponieważ może wystąpić kilka zjawisk przez nas niepożądanych, o których piszę poniżej.


Czujnik częściowo nad linią, a częściowo poza linią

Co się stanie, gdy czujnik będzie częściowo nad linią, a częściowo poza nią?

Tutaj najszybciej ujawnia się analogowa charakterystyka czujnika. Elementem czułym na odbite światło jest fototranzystor, a jak zapewne wiesz nie jest on elementem zero-jedynkowym, tylko ma swoją charakterystykę, a ta  nie jest zero-jedynkowa.

Zobaczmy jak wygląda to na przykładzie CNY70. Zerkamy do datasheet i znajdujemy wykres:

Wykresy te pokazują:

• jaki poziom sygnału otrzymamy, zależnie od odległości (d) czujnika od powierzchni,
• jak na poziom sygnału wpływa przemieszczenie (s) czujnika względem krawędzi linii.

Powyższy wykres szczegółowo opisałem w artykule: Transoptor odbiciowy: Wpływ ruchu powierzchni na odpowiedź transoptora


Odległość transoptora od powierzchni nie jest stała

W czasie jazdy robota, w zależności od jego konstrukcji i/lub powierzchni po której jedzie, odległość transoptora odbiciowego od powierzchni może się zmieniać. Ma to bezpośredni wpływ na wartość sygnału jakim odpowiada transoptor.

W przypadku transopotorów odbiciowych zależność odpowiedzi transoptora od odległości czujnika od powierzchni jest bardzo różna, ale w większości przypadków różnica 2-3mm znacząco wpływa na wartość sygnału na wyjściu transoptora.

Możesz to zaobserwować na wykresie z poprzedniego punktu (powyżej). Zauważ, jak zmienia się wartość sygnału (bardziej płaski) wraz z niewielkim zwiększeniem odległości oznaczonej literką d, np. z 1mm do 4mm.

O problemie dot. odległości czujników od podłoża vs różne konstrukcje linefollowerów pisałem także w artykule: Linefollower - Listwa czujników linii.

Podłoże nigdy nie jest idealnie czarne lub białe

W robotyce należy być realistą i nie można przyjmować, że czarne podłoże jest idealnie czarne i całkowicie pochłania emitowane przez transoptor światło. Zawsze jakaś część światła zostanie odbita w kierunku fototranzystora czujnika.

Podobnie jest oczywiście w przypadku białego podłoża, czy linii. Może być przecież zabrudzone albo mniej lub bardziej matowe, czy błyszczące.


Inne "niecyfrowe" parametry i zjawiska

Na to że sygnał z transoptora nie jest stricte zero-jedynkowy, mają także wpływ inne parametry i zjawiska:

• jak każdy element elektroniczny, także i transoptor ma swoje charakterystyki, które nie są zero-jedynkowe,
• sposób montażu transoptora także może być istotny,
• zabrudzenia powierzchni obserwującej transoptora także mają wpływ na nierównomierne wskazywanie przez poszczególne transoptory,
• itd., itp. ...

Większość tych które dotyczą parametrów transoptora omówiłem w cyklu dot. Transoptorów odbiciowych.

---

Jednak sygnał analogowy! Wyznaczamy "Próg decyzji".

Z powyższych przypadków możemy wyciągnąć ostateczny wniosek, że:

Sygnał dostarczany przez transoptor odbiciowy jest sygnałem analogowym.

Skoro jest analogowy, to musimy go przekształcić na sygnał cyfrowy zgodnie z naszymi potrzebami. Oznacza to, że musimy wyznaczyć jakiś próg wartości sygnału analogowego z transoptora, przy którym nastąpi rozpoznanie w postaci:

• czujnik jest nad linią (czyli jedynka)
• czujnik jest poza linią (czyli zero).

który nazwiemy sobie progiem decyzji.

Powinniśmy to zrobić, niezależnie od tego, czy zastosujemy rozwiązanie sprzętowe, czy programowe.

Czy można na sztywno przyjąć, że jest to np. 50%?

Nie można ze względu na te wszystkie przypadki, które opisałem wyżej. W robocie, który ma się poruszać po różnych podłożach (np. na różnych zawodach), aby być pewnym pracy robota należy na każdej trasie (np. przed wyścigiem) dokonać kalibracji czujników linii.

Kalibracja może być dokonana przed rozpoczęciem jazdy lub robiona "w locie"  w czasie jazdy. To drugie daje robotowi szansę dostosowania się do zmieniających się warunków na trasie (jeżeli jest to dla nas istotne), ale komplikuje algorytm i zwiększa obciążenie mikrokontrolera. Coś za coś :-)


Praktyczne rozwiązania

Jak już wspomniałem wyżej moduł czujników może zawierać sprzętowe (dodatkowe zewnętrze elementy) rozwiązanie zmiany sygnału analogowego na cyfrowy lub można to wykonać programowo.


Rozwiązanie sprzętowe 

Rozwiązanie sprzętowe, to transoptory podłączone do zewnętrznych komparatorów (zamieniających sygnał analogowy na cyfrowy), a sygnały wyjściowe podłączone do dowolnych wejść cyfrowych mikrokontrolera:

Czujnik linii z wykorzystaniem transoptora i komparatora ze stałym progiem decyzji.

Jeżeli nie wiesz jak działa komparator możesz przeczytać artykuły:

• Komparator (wraz z symulatorem i filmem),
• Mikrokontroler AVR: Komparator analogowy.

Wyjaśnienia wymagają rezystory:

• R1 wraz z R2 tworzą rezystorowy dzielnik napięcia, którym ustawiamy na stałe wartość progu decyzji. Rezystory te mogą być przy każdym komparatorze, ale można także wykorzystać jeden wspólny dzielnik dla wszystkich komparatorów,
• R3 jest niezbędny ze względu na to, że wyjście komparatora jest typu otwarty kolektor. Rezystor ten można zastąpić wewnętrznymi rezystorami pull-up, które są dostępne w pinach wejść cyfrowych w większości mikrokontrolerów. W takim przypadku wystarczy je włączyć za pomocą programu. Jednakże należy wziąć pod uwagę, że taki rezystor ma z reguły kilkadziesiąt kΩ, co może mieć wpływ na szybkość działania tak zbudowanego układu rozpoznawania linii.

Zalety:

• szybki odczyt dużej ilości czujników naraz,
• odciążenie mikrokontrolera,
• uproszczenie programu,
• wykorzystanie dowolnych wejść cyfrowych (pinów) mikrokontrolera.

Wady:

• próg decyzji ustawiony na stałe bez możliwości regulacji,
• dodatkowe elementy elektroniczne (większe koszty),
• dodatkowy ciężar (istotne w dla robotów startujących w zawodach).

Ponieważ warto mieć możliwość regulacji progu decyzji, stąd możemy zastosować dwa rozwiązania:

Rozwiązanie sprzętowe - wersja A

Najprostszym rozwiązaniem ustawienia napięcia progu decyzji jest wykorzystanie potencjometru montażowego. Zamieniamy więc dzielnik rezystorowy na potencjometr montażowy:

Czujnik linii z wykorzystaniem transoptora i komparatora
z progiem decyzji regulowanym potencjometrem.

Uwagi dot. R3, są takie same jak w poprzednim przypadku.

Podobnie jak w poprzednim przypadku, także i tutaj potencjometr może ustalać napięcie progu decyzji dla wszystkich komparatorów czujnika linii.

Zaletą jest posiadanie możliwości regulacji progu decyzji w zależności od powierzchni podłoża.

Wadą takiego rozwiązania jest fakt, iż potencjometr montażowy nie może być ustawiany przez program, w związku z czym projektant robota sam musi dobrać "ręcznie" odpowiednie ustawienie do danej powierzchni, po której robot będzie się poruszał.


Rozwiązanie sprzętowe - wersja B (polecana)

Innym rozwiązaniem sprzętowym, które polecam jest wykorzystanie sygnału PWM, dzięki któremu możemy programowo zmieniać próg decyzji w zależności od potrzeb:

Czujnik linii z wykorzystaniem transoptora i komparatora
z progiem decyzji regulowanym sygnałem PWM.

Uwagi dot. R3, są takie same jak w poprzednich przypadkach.

Zamiast dzielnika rezystorowego lub potencjometru, stosujemy pin generujący stały sygnał PWM oraz prosty filtr dolnoprzepustowy (RC), złożony z rezystora R6 oraz kondensatorów C1 i C2. Także i w tym przypadku sygnał PWM może ustalać napięcie progu decyzji dla wszystkich komparatorów czujnika linii.

Dlaczego dwa kondensatory? Zależy nam na tym, by wykrywanie linii było jak najdokładniejsze, dlatego powinniśmy zadbać o to, by napięcie na wejściach ujemnych komparatorów, było możliwie najstabilniejsze. Ponieważ sygnał PWM, to przebieg prostokątny, stąd też należy poświęcić uwagę na ten fragment czujnika linii, by nie okazało się, że napięcie nie jest stabilne. Szczegóły dot. doboru filtra RC, znajdziesz w jednym z artykułów dot. RoDonM8.

Zaletą takiego rozwiązania jest możliwość automatycznego dostosowania progu decyzji w zależności od jakości podłoża i linii.

Wadą może być fakt, iż należy poświęcić jeden z timerów generujących sygnał PWM wraz z dodatkowym pinem. W przypadku braku timera z funkcją PWM można pokusić się o generowanie sygnału PWM programowo, ale może to wpłynąć na jakość pracy czujnika linii (programowe PWM może nie być idealne z powodu zależności czasowych w wykonywaniu programu).

Który komparator wybrać?

Najtańszy! :-)

Dobrym i tanim komparatorem jest popularny LM339 z rodziny LM339, LM239, LM2901, LM2901V, NCV2901, MC3302, który zawiera w sobie cztery niezależne komparatory i kosztuje zaledwie 0,36zł brutto (cena dn. 2013.08.16):

Schemat blokowy komparatora z rodziny LM339.

Innym równie tanim i dobrym do tych celów jest LM393 z rodziny LM193, LM2903, LM293, LM393, który w jednej obudowie zawiera dwa komparatory:

Schemat blokowy komparatora z rodziny LM393.

Dwie istotne uwagi dot. stosowania komparatorów:

Jeżeli ilość transoptorów nie będzie dokładnie odpowiadała ilości komparatorów w układach, gdy np. masz 10 czujników, to:

• nie mieszaj różnych komparatorów, ponieważ mają one różne charakterystyki, a robot ma jeden wspólny sygnał progu decyzji, czyli nie stosuj 2xLM339 + 1xLM393, tylko 3xLM339 lub 5xLM393
• niewykorzystane wejścia komparatorów nie pozostawiaj bez polaryzacji ponieważ powstaną "antenki", a wyjścia będą "wariować" generując zakłócenia. Jeżeli masz taką sytuację podłącz niewykorzystane wejścia do Vcc lub GND. Wyjścia mogą być niepodłączone.

Docelowe rozwiązanie powinno więc wyglądać następująco:

Schemat listwy czujników (transoptorów)
z wykorzystaniem komparatorów.

przy czym filtr sygnału PWM możesz opracować we własnym zakresie np. dwustopniowy, a do ich obliczania możesz wykorzystać dostępne kalkulatory.


Uwagi końcowe rozwiązania sprzętowego

Należy tutaj zwrócić uwagę na fakt, że mając wspólną regulację progu decyzji mogą występować minimalne różnice między pracą poszczególnych komparatorów. Jak każdy układ scalony także i one mają swoje charakterystyki, a większość parametrów zawiera się w przedziałach minimum i maksimum.

Na poziomie amatorskim w większości przypadków nie będzie to miało znaczenia, o tyle przy projektach, które liczą na złoty medal na zawodach warto pokusić się, by sprawdzić, czy wszystkie czujniki wraz komparatorami działają jednakowo w zależności od ustawienia progu decyzji. To żmudna praca, ale czego się nie robi dla medali :-)

Innym prostym rozwiązaniem, jest zastosowanie komparatorów pochodzących z tej samej partii (rolki), co zwiększa prawdopodobieństwo użycia komparatorów jednakowych parametrach uzyskanych w procesie produkcji danej partii..

Rozwiązanie programowe

Drugim sposobem, jest wykorzystanie przetwornika analogowo-cyfrowego (ADC) dostępnego w mikrokontrolerze. W takim przypadku, sygnały z czujników podłączamy bezpośrednio do wejść ADC mikrokontrolera i wykorzystując wewnętrzny multiplekser "przemiatamy" nasze czujniki według kolejności, którą sobie ustalimy:

Czujnik linii z wykorzystaniem transoptora i przetwornika ADC
mikrokontrolera z progiem decyzji regulowanym programowo.

Rezystor R4 spełnia tę samą rolę co R3 w rozwiązaniu sprzętowym omawianym wcześniej i także może być zastąpiony wewnętrznym rezystorem pull-up o ile mikrokontroler może go mieć włączony w momencie gdy wejście wykorzystywane jest jako kanał pomiarowy przetwornika ADC. Także i tutaj wartość rezystora może determinować szybkość działania czujników linii.

Zalety:

• programowa kalibracja (bardzo użyteczna funkcja),
• mniej elementów zewnętrznych,
• mniejszy ciężar robota,
• z reguły mniejsze koszty.

Wady:

• wymagana spora ilość wejść przetwornika ADC,
• dłuższy czas odczytu kompletu czujników,
• zwiększenie obciążenia mikrokontrolera,
• zwiększenie stopnia skomplikowania programu.

Podsumowanie

Wykrywanie położenia linii względem robota, nie jest zadaniem specjalnie trudnym, ale nie jest też błahym. Należy wziąć pod uwagę sporo czynników, które decydują o zastosowanym rozwiązaniu. Zlekceważenie niektórych z nich, może zakończyć się podjęciem złej decyzji przez program, co w przypadku np. linefollowera może skończyć się utratą dobrej lokaty na zawodach.

Dlatego we wszystkich projektach polecam w szczególności zwracać uwagę na dopracowanie czujników:

Dbaj o dane wejściowe ponieważ:

• nawet najlepszy program nie podejmie właściwych decyzji na podstawie złych danych,
• program łatwo można poprawić, a elektronikę już niekoniecznie.