[c] ATmega 128, Timer 3

[Sokolsok]

Witam! Otóż mam pewien problem z Timerem. Zbudowałem robota w oparciu o Mege128 i sporym problemem okazała się jego jazda "do przodu". Ma napęd różnicowy, więc ważna jest jednakowa prędkość obu kół. Wiadomo, że silniki (mimo teoretycznie takich samych parametrów) mają różne charakterystyki i tym się bardzo nie przejąłem. Zastosowałem prosty sposób regulacji. Na podstawie danych z enkoderów obliczam orientację i jeżeli się odchyli w którąś stronę to o jakąś tam wartość zmniejszam prędkość jednego lub drugiego koła. Nie sprawdza się to jednak dobrze, teoretycznie jedzie prosto, ale sinusojdą.. I pomyślałem, że lepszym rozwiązaniem będzie liczenie czasu między kolejnymi tikami enkoderów i na tej podstawie korygować prędkości kół. I teraz tak użyłem Timera 1 do PWM, Timera 2 do czujników ultradźwiękowych więc został mi 16 bitowy timer 3. Czy za pomocą jednego timera da rade mierzyć czasy w dwóch kołach? Pewnie tak, tylko nie mam pomysłu jak to zrobić.. Z góry dzięki za pomoc:)

[Stonka]

Możesz co określony czas sprawdzać ilość impulsów.

( Wartości przypadkowe: )

Np. co 1 ms sprawdzasz ilość impulsów z enkodera, jeśli z lewego koła było ich 20 a z prawego 21, to musisz lekko zwolnić prawym... Itd.

Z tego co spojrzałem na DS tego procka możesz spokojnie na Timerze3 zrobić coś takiego generując przerwanie w stałym odstępie czasowym. W przerwaniu sprawdzasz aktualny stan enkoderów i potem możesz sobie porównać odpowiednie wartości.

Ten sposób jest dobry przy odpowiednio dużej rozdzielczości enkoderów.

Jeśli chciałbyś mierzyć odstępy między impulsami, to (prawdopodobnie) wystarczyłoby uruchomić Timer i przy każdym pojawieniu się impulsu sprawdzać aktualny stan timera. Przy następnym pojawieniu się impulsu liczysz różnicę i masz czas pomiędzy tyknięciami... Tego nie próbowałem, ale wygląda dobrze 😉.

[grabo]

Napisz coś więcej o samych enkoderach: ile kanałów, jaka rozdzielczość, może jakiś schemat połączeń, wtedy będzie łatwiej coś doradzić i pomóc 🙂

[marek1707]

Z jednym wejściem IC będzie trudno ale może jakieś zewnętrzne przełączanie tego wejścia? Taki multiplekser na 2 bramkach czy tranzystorach itp sterowany 2 pinami któregoś portu? Nie byłoby wtedy jednoczesnego pomiaru ale za to jakby już mierzyło - to przynajmniej dokładnie 🙂 xMegi mają tych wejść do jednego timera więcej..

A może zrobić to qasi-analogowo? Masz wolne wejście ADC?

Można zrobić układ na dwóch przerzutnikach 74HC74 i bramce NAND czyli kanoniczny komparator częstotliwości. Jego wyjście można przepuścić przez prosty dolnoprzepustowy filtr RC a trend napięcia na wyjściu (mierzonego przez ADC) odzwierciedlał będzie różnicę szybkości. Algorytm odpalałby kolejne konwersje A/D i próbował doprowadzić napięcie na kondensatorze do połowy Vref, czyli do odczytu liczby 512 z ADC. Hm?

Możnaby też zrobić bez przerzutników, choć jakaś standaryzacja impulsów z enkoderów by sie przydała. Proste dwa klucze tranzystorowe "pompowałyby" przeciwstawne paczki ładunku a na kondensatorze gromadziłaby się różnica prędkości. Całość startowałaby od połowy Vref - cokolwiek to znaczy i każdy impuls z enkodera dodawałby lub odejmował paczkę ładunku - najlepiej przez źródło prądowe ale w tym zastosowaniu wystarczą oporniki. Reszta czyli pomiary, sprzężenie zwrotne od różnicy prędkości itp - jw.

Kolejnym moim pomysłem jest zrobienie układu cyfrowego, który będzie dawał na wyjściu przebieg o wypełnieniu zależnym od różnicy częstotliwości - to raczej proste. No i teraz bramkujemy tym zegar timera - już w procesorze i patrzymy ile zliczył przez pewnien okres czasu. Jeśli wypełnienie będzie 50% (czyli częstotliwości są równe) to timer powinien zliczyć połowę impulsów zegara jakie w danym czasie miał szansę zliczyć. No to odczytujemy timer i mamy wynik, zerujemy go, znów puszczamy i tak w kółko.

No nie wiem czy to się Wam podoba, jeszcze pomyślę..

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Sokolsok]

Dzięki za zainteresowanie tematem

@grabo

Rozdzielczość enkoderów to tylko 17. Na wale silników są luzy i nie bardzo mam jak tą rozdzielczość podnieść. Oczywiście mogę przerwania ustawić raz na zbocze narastające raz na opadające co daje mi rozdzielczość 34. Wykorzystuję po jednym kanale na enkoder. Silniki są silnikami DC z przekładnią sterowaną za pośrednictwem L298. Wyjścia Ena i EnB są wyjściami PWM.

@Stonka

Z tym liczeniem impulsów co określony jest pewien problem, mianowicie tarcze kodowe nie są ustawione w identycznej pozycji i np. mimo, że koła kręcą się z taką samą prędkością jedno koło wyprzedza impulsami drugie. Wtedy w momencie wybicia tej 1 ms, według zliczonych impulsów koło drugie ma opóźnienie. Może to nie byłby problem przy dużej rozdzielczości impulsów, u mnie jednak niestety za duża ona nie jest.

A jeśli chodzi o drugą część Twojego posta to ten pomysł jest genialny w swojej prostocie:D Będzie trzeba tylko ogarnąć sprawę w przypadku przepełnienia się licznika. Ale to już powinno być w miarę proste:)

@marek1707

Niestety hardware robota jest już skończony.. Wyjść ADC nie używam i od początku nie planowałem, więc nawet ich nie wyprowadziłem na płytce.. Mam dokładnie to wyprowadzone czego używam więc niestety jedynie rozwiązania softwarowe wchodzą w grę.

I czemu będzie trudno jednym timerem mierzyć? W sumie też mi się tak wydawało, że jakiś multiplekser będzie niezbędny, ale jak Stonka podsunął? Timer sobie leciał, w swoich przerwaniach (załóżmy co 1ms) jakąś zmienną by inkrementował, a w przerwaniach enkoderów zliczałbym różnicę miedzy wartością poprzednią, a aktualną tej zmiennej. Teraz tylko jakiś PID i powinno hulać😉 - w teorii

[marek1707]

Szkoda, czasem proste układy zewnętrzne moga bardzo odciążyć procesor.

Stonka ma rację, w celu zwiększenia rozdzielczości możesz zrobić tak:

- Puść timer 3 wolno, niech chodzi w trybie normal (mode 0) z preskalerem takim, byś miał sensowną ale nie za dużą rozdzielczość. Przy 17 impulsach na obrót i np. 20 rpm masz 340Hz. Wybierz taką szybkość zegara timera, by zdążył zliczyć przynajmniej do kilkuset w czasie tych 3ms. To będzie najkrótszy zliczany czas i najmniejszy (liczbowo) wynik.

- Przerwanie od przepełnienia timera 3 obsługuj programowo, inkrmentując jakiś statyczny licznik 8 lub 16-bitowy. Dostaniesz wtedy rozszerzenie timera do 24 lub 32 bitów. Tego nie musisz implementować jeśli założysz, że poniżej pewnej prędkości algorytmy prostowania drogi po prostu nie działają. Z resztą przy spełnionym poprzednim warunku, 16-bitowy timer pozwoli na spadek szybkości do prawie zatrzymania (1Hz z enkodera ?).

- Impulsy z enkoderów (chyba są doprowadzone do procesora?) obsługuj w przerwaniach - każdy w osobnym. Odczytuj tam timer "w locie" uważając, by nie przeczytać czegoś głupiego ale są na to metody. W połączeniu z zapamiętanym stanem poprzednim (16-, 24- lub 32 bitowym, zależy jak zrobisz) masz okres impulsów. Wystarczy przecież odjąć.

Ważne, by jeden pomiar nie zakłócał drugiego więc timer musi pracować bez zatrzymań. Taka sprzętowo-programowa metoda ma tę wadę, że ważny jest czas obsługi przerwania. Ponieważ enkodery pracują asynchronicznie to będzie się zdarzać, że aktywne zbocze od jednego będzie przychodziło w trakcie trwania funkcji obsługi przerwania od drugiego. Wtedy obsługa będzie musiała chwilę poczekać no i opóźnienie, czyli błąd pomiaru gotowy. Im czasy obsługi będą krótsze i procesor szybszy, tym szansa na to mniejsza. W każdym razie nie brałbym do dalszych etapów bezkrytycznie czasów zmierzonych wprost, tylko uśredniał je za np. 2 lub 4 ostatnio zmierzone impulsy. Jeśli zrobisz sobie takie FIFO wyników pomiarów i dla każdego nowego będziesz liczył średnią z kilku ostatnich, to nowy, odfiltrowany wynik będziesz miał za każdym razem. To dużo częściej niż przy pomiarze liczby impulsów w pewnym czasie.

Tego motywu pt. "tarcze kodowe nie są ustawione w identycznej pozycji" nie rozumiem. Przecież koła też nie, więc z założenia ciągi impulsów z enkoderów trzeba traktować jako zupełnie niezależne i asynchroniczne.