Line follower GreenNight

[sailo]

Oczywiście, masz racje odczyty ADC będą dużo wolniejsze, ale nie na tyle wolne żeby mieć znaczący wpływ na jazdę.

[GAndaLF]

ADC w AVRach ma swój własny zegar pracujący z maksymalną częstotliwością około 250kHz. Potrzebujemy wielu kanałów i po kolei będziemy je przełączać. Tak więc przy każdej konwersji będzie dokonywana jeszcze inicjalizacja kanału przez co pomiar wyniesie 25 cykli zegara ADC. Zgodnie z tymi obliczeniami pomiar otrzymamy co 100us.

Natomiast jeżeli używamy pomiarów cyfrowych, wynik mamy praktycznie od razu. Jeżeli taktujemy naszą atmegę kwarcem 16MHz i przyjmiemy, że przerzucenie danej z portu do pamięci zajmuje nawet 10 cykli zegara, otrzymujemy 625ns na pomiar. Poza tym wejścia ośmiu pinów na jednym porcie możemy odczytać jednocześnie zaoszczędzając kolejny czas.

Różnica czasu jest więc całkiem spora. Natomiast wykorzystanie tego zysku zależy już od bezwładności silników.

Jeżeli ktoś chciał by koniecznie robić linefollowera na ADC, radzę zainteresować się PICami. Niektóre mają po 20 i więcej wejść ADC.

[Grzesieq94]

A jak mają się różnice w czasie odczytu między ATMEGAMI i XMEGAMI? XMEGI mają dużo szybsze ADC czyli 2000-15 ksps... Czyli czysto teoretycznie ponad 130 razy szybsze.

[GAndaLF]

Z Xmegami nie miałem nigdy do czynienia, ale swoich informacji nie biorę z powietrza. Wszystko można znaleźć w datasheecie, wystarczy chwilę poszukać. Z tego co widzę w pierwszym lepszym pdfie xmegi mają 4 niezależne kanały konwersji ADC a czas pojedynczej to kilka us więc ADC będzie o wiele szybsze niż w atmegach. Ale w dalszym ciągu odczytywanie cyfrowe jest po prostu bardziej opłacalne. Nie dość, że dużo szybsze, to jeszcze mniej obciążające kod programu.

[MirekCz]

Niektóre ARMy są pod tym względem też fajne - w małych STM32 masz np. dwa ADC każdy z czasem konwersji 1us i system DMA, który pozwala pobrać Tobie wiele próbek z różnych portów bez zajmowania czasu CPU. Czyli np. w 4us możesz zebrać dane analogowe z 8 czujników i w tym samym czasie obrobić dane z poprzedniego pomiaru na CPU. Czyli co 4us masz nowe obliczenia co robi robot (o ile algorytm sterujący jest bardzo prosty)

Korzystanie z ADC ma takie zalety, że możesz dokładniej oszacować pozycję linii przy tej samej ilości czujników.

Cała część analogowa (fototranzystor, komparator itd.) też ma jakiś czas ustalania swojej wartości - zależny od dobranych komponentów. Stwierdzenie, że jest to tylko powiązane z czasem odczytania portu cyfrowego jest mylne. Czas zmiany stanu wyjścia komparatora może wynosić np. 1us.

Warto jednak pamiętać, że przez 1us robot jadący 1m/s pokonuje dystans 0,001mm. Nie ma sensu mocno się przejmować kilkoma us. Algorytm sterujący jest dużo, dużo ważniejszy i mała poprawka w nim wielokrotnie więcej zdziała.

[GAndaLF]

No faktycznie zapomniałem o czasie ustalania fotoelementów ale dalej uważam, że odczyty cyfrowe będą lepsze. Choćby dlatego, że wystarczy słabszy mikrokontroler żeby je obsłużyć z dobrą wydajnością, są proste do obsługi programowej i możesz je podłączyć do każdego pinu. Oczywiście to nie oznacza, że sposób z ADC jest zły. Po prostu ja wolę cyfrowy.

[SWJ]

A jak mają się różnice w czasie odczytu między ATMEGAMI i XMEGAMI? XMEGI mają dużo szybsze ADC czyli 2000-15 ksps... Czyli czysto teoretycznie ponad 130 razy szybsze.

Na Xmega z użyciem tylko wewnętrznych ADC można zrobić całkiem szybki oscyloskop - jak pamiętam można mierzyć nim przebiegi o szybkości nawet 600 kHz - można podejrzeć na elektrodzie mały projekt oscyloskopu - a także kilka w necie.

Jeśli chodzi szybkość zegara to na dzień dobry mamy 32 MHz - ale testowałem taktowanie procka z wbudowanego PLL i kwarcu na 56 MHz - działa ładnie stabilnie (rdzeń i peryferia) - do testów ADC narazie jeszcze nie doszedłem...

Xmega128A3 ma 16 kanałów ADC i dwa DAC - wiec jak znalazł do małych szybkich robocików. Jeśli zastosujemy wbudowane generatory nie marnujemy nóżek na kwarce.

Także myślę że spokojnie można już uzyskać szybkość "porównywalną" do analogowych komparatorów przy tej szybkości robotów.

( Dodatkowo wspiera te procki Bascom ... )

[Hudyvolt]

Przy pomocy przejściówki. Co prawda jest na wał sześciokątny, ale wystarczy lekko rozwiercić i pasuje idealnie na wał silnika Pololu.

jakiej średnicy wiertła użyliście do tego zabiegu?

[fish]

Gdzie można dostać takie złącza i taśmę, którą łączycie płytkę główną z czujnikami? I w której bibliotece w Eaglu szukać tego złącza?

[Treker (Damian Szymański)]

Złącza i taśmy są w TME, biblioteki do Eagle trzeba sobie narysować.

Edit:

Botland też już ma wszystko u siebie razem z bibliotekami:

http://botland.com.pl/przewody/249-tasma-20-zyl-raster-1mm.html

http://botland.com.pl/przewody/248-zlacze-ffc-fpc-20-pin.html

[fish]

Cieszy mnie taka reakcja, sailo, ownya, plus dla was

[fish]

Kolejne pytanie z mojej strony - można prosić o wytłumaczenie tego wzmacniacza tranzystorowego przy sterowaniu turbiną? Nie wystarczyłby pojedynczy tranzystor bipolarny?

[Armir]

Na bipolarnym miał byś spory spadek i wydzielał by trochę mocy. Jeden z tranzystorów działa jako bramka not ,a następny kolejną. Na wyjściu sygnał jest taki sam albo prawie taki sam jak na wejściu. Ogólnie chodzi o zabezpieczenie procesora. Jeżeli się mylę to niech ktoś mnie poprawi.

[sailo]

Tranzystory bipolarne służą do wzmocnienia sygnału sterującego mosfetem. W tej konfiguracji (wspólnego emitera) pojedynczy tranzystor odwraca polaryzacje sygnału, dlatego zastosowaliśmy drugi (oczywiście można by to rozwiązać programowo, zrobiliśmy tak dla wygody). Tak jak napisał armir na samym tranzystorze bipolarnym mielibyśmy większe straty mocy. Dodatkowo mosfety są sterowane napięciem oraz charakteryzują się wysoką rezystancją wejściową.

[fish]

sailo, z tego co widzę to sterujecie turbinę napięciem niestabilizowanym prosto z pakietu, tak? Silnik Graupner 280 jest nominalnie na 6V, oznacza to, że po prostu nie przesadzacie z PWMem? Ponadto, znalazłem, że ten silnik ciągnie maksymalnie 1.6A, a wy piszecie o 3A. Silnik nie dostaje za bardzo w kość?