Elektroda.pl
Elektroda.pl
X
Arrow Multisolution Day
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Robot - enkodery... jak to wszystko zgrać...?

zerpo 29 Lip 2005 14:36 2821 8
  • #1 29 Lip 2005 14:36
    zerpo
    Poziom 22  

    Panuję zbudować robocika, w sumie podwozie jest juz gotowe (z LEGO oczywiście). Napędzany dwoma silnikami od CD ROMa poprzez przekładnie ślimakową (2 koła napędowe)... Chcę na tej przekładni umieścić enkoder od myszki. Przekładnia ma przełożenie ok. 1:23 (23 obroty ślimaka to 1 obrót koła). Ale wracając do konkretów.
    Przy pomocy enkoderów chcę robić 2 rzeczy:
    1. Synchronizować silniki, aby robot jechał idealnie prosto. Na podstawie sygnału od enkoderów generowana by była odpowiednia korekta dla PWM.
    2. Zliczać drogę oraz kąty jakie zakreślił robot.

    Chcę wykorzystać do tego ATmega8 lub 16, tylko nie wiem, jak to dokładnie sprząc z µC. Jeden z pomysłów jest taki (rys. poniżej) do każdego enk. licznik 8-bit, dalej bufor i to do uC. I już można odczytywać sygnał.
    Może zrezygnować z bufora i 8-bitowe liczniki podłaczyć pozpośrednio do 2ch Portów uC, ale wtedy zajmę aż 16 Pinów + 2 do zerowania liczników.
    Myślełem również, aby podłaczyć enk. do Timera uC i tam zliczać, bez dodatkowych liczników (ale wtedy może mi nie starczyć timerów do generowania 2ch PWMów).
    I najważniejsze: Aby regulować PWM oraz zliczać drogę trzeba co jakiś czas zerować liczniki. Aby jedno działo z drugim, to czy nie będzie potrzeba zorganizowania 2-ch źródeł (dla każedgo koła) od enkod.? Chyba, żeby to jakoś uwzględnić w porgramie, np. regulując PWM nastepuje kasowanie licznków, w tym czasie stan przejechanej drogi musi zostać zapisany lub jakoś dodany do dotychczasowego... (ale operacje arytmet. w ASM są trochę mozolne ;-) )

    Jeśli ktoś ma jakieś doświadczenie z tym, lub jakieś ciekawe pomysły, to będe bardzo rad :-)

    PS. Właściwie nie wiem, czy w ogóle konieczne jest zerowanie liczników, jednak na pewno bardzo by ułatwiło to sprawę od strony programowej....

    0 8
  • Arrow Multisolution Day
  • #2 29 Lip 2005 15:26
    MirekCz
    Poziom 35  

    Pytanie nr 1.
    Jak szybko twoj robot bedzie sie poruszal/ile bedzie generowal sygnalow na sekunde?

    Jezeli ta liczba jest mala (dajmy kilkaset sygnalow z enkodera na sekunde) to mozesz po prostu zrobic co 1ms krotko petle, ktora sprawdza stan enkoderow i wg. tego oblicza przebyta droge/kat itd. (czyli enkodery podpinasz prosto pod piny procesora)

    Jezeli ta liczba jest duza, to najlepiej dodac drugi mikrokontroler, na ktorym bedziesz te sygnaly zliczal, a nastepnie poprzez jakas magistrale (chociazby rs232) przesylal do "glownego" procka. Na ten mikrokontroler moglbys tez przeniesc wtedy obsluge silnikow (czyli glowny procek np mowi jedz prosto, a ten mikroprocek robi wszystko zeby jechac prosto i zwraca do glownego procka dane, ze przejechal tyle i tyle w kierunku x)

    Wzgledna trzecia mozliwosc, jezeli masz duzo czasu na glownym procku do "spalenia", to nawet przy sporej liczbie impulsow mozesz za pomoca "xorow" podlaczyc enkodery razem do wyjscia generujacego przerwanie (musialbys chyba uzyc int0 i int1, bo z tego co widze mozna je tylko ustawic na krawedz rosnaca lub malejaca, a nie na obydwie). W ten sposob po wywolaniu przerwania musisz sprawdzic tylko na ktorym enkoderze nastapila zmiana i odpowiednio naliczyc to w programie. (czyli dla dwoch kol uzywasz 6 pinow - 2 to int0 i int1, 4 to wejscia z enkoderow - po 2 na kolo)

    0
  • Arrow Multisolution Day
  • #3 29 Lip 2005 17:41
    zerpo
    Poziom 22  

    Po obliczeniach wychodzi mi jakies 500 - 600 impulsów na sekunde, nawet nie tak mało. Mógłbym przenieść enkoder bezpośredno na koło, ale wtedy bardzo strace na rozdzielczości (ok 25impulsów/sek :/ ).
    Chyba zdecyduje sie na rozwiązanie z obrazka, które załączyłem poprzednio... będzie trzeba wykonać serię testów.
    Sam procek nie ma dużo do zrobienia, głównie zliczanie drogi, regulacja PWM, regowanie na "zderzenia" z przeszkodami, odtwarzanie zadanej drogi i oczywiście przesłanie odpowiednich danych do silników i jeszcze odbieraniech danych z PCta (sterowanie).
    Nie wiem czy dobrze zrozumiełem Twoje rozwiązanie z XORami. Bramki generują wtedy przerwanie, jeśli koła nie kręcą się równo, jeśli dobrze rozumiem?

    PS. Nie bawie się w rozpoznawanie kierunku obrotu, wystarcza mi tylko prędkość.

    0
  • #4 29 Lip 2005 18:05
    MirekCz
    Poziom 35  

    hmm, rozpoznawanie obrotow jak robot ma jezdzic w dwie strony to podstawa.. :)

    To do xorow jest proste. Robisz xor miedzy wszystkimi enkoderami. W ten sposob jezeli stan na jednym z nich sie zmienia to generuje sie przerwanie i procek sprawdze co sie dzieje - nie musisz miec ustawionego na sztywno timera.

    Przy takiej liczbie impulsow zapuscilbym jakis timer co ~1ms i po prostu sprawdzal wejscia. Nie powinno to obciazyc proca bardziej niz kilka %. Ten uklad co narysowales jest cholernie skomplikowany i chyba mija sie zupelnie z celem. Plytka ci sie rozrosnie jak cholera.

    0
  • #5 31 Lip 2005 08:21
    Coyote~
    Poziom 20  

    Wydaje mi się, że zerpo wcale nie musi sprawdzać kierunku obrotu... Koła robota będą na przekładni ślimakowej, więc to raczej sztywne połączenie i nie pozwoli na obrócenie wału silnika przez moment na kole (zależy to co prawda od modułu ślimaka, ale zwykle jest sztywne, przynajmniej LEGO na pewno), więc kierunek obrotów koła będzie się zgadzał z aktualnym wysterowaniem....

    zerpo, co do twojego schematu - nie wiem czy dobrze mi się wydaje, ale w przypadku użycia bufora zerowanie liczników jednocześnie może spowodować zgubienie impulsu na tym wcześniej sprawdzanym... ale może nie będzie to wielka niedokładność...


    Pozdrawiam

    0
  • #6 31 Lip 2005 10:12
    zerpo
    Poziom 22  

    No właśnie, te enkodery zabiły mi największego ćwieka...
    W przyszłym tygodniu złoże schemat z tymi licznikami na sucho i zobaczymy. Potestuje też inne rozwiązania.
    Co do kierunku obrotów, to pobawie się tym w następnym projekcie, teraz postanowiłem określać kierunkek obr. na podstawie tego, co wysyła uC do sterownika silników (zakładając, że nie następuje żadne uderzenie, zew. przesunięcie, czy coś takiego...).
    Czy wiecie może z jak dużą częstotliwością jest w stanie zliczać enk. ze zwykłej myszy (takiej za 30-40zł) ?

    0
  • #7 31 Lip 2005 11:46
    MirekCz
    Poziom 35  

    Zerpo:Problemem jest to, ze robot ma bezwladnosc i zmiana kierunku silnikow nie oznacza automatycznie zmiany kierunku jazdy. A robienie enkodera, ktory podaje bledne wyniki po prostu mija sie z celem.
    Mozna to "zniwelowac" poprzez najpierw hamowanie robota itd..., ale to tylko kolejne problemy i ograniczenia do czy tak malo efektywnego rozwiazania

    Co do samego enkodera, zakladam przynajmniej kilka tysiecy zmian stanow/sekunde (takie sa wymogi, zeby myszka dzialala wg. zalozen)... chociaz poderzewam, ze w rzeczywistosci jest to przynajmniej kilkadziesiat tysiecy. (dla przykladu optoizolator ma czas reakcji rzedu kilku-kilkunastu us)

    0
  • #8 13 Sie 2005 16:18
    zerpo
    Poziom 22  

    trochę kombinowałem i poradziłem sobie tak:
    Jako tarcze enkoderów zastosowałem zwykłe kółko z LEGO, które ma na swoim obwodzie 6 dziurek, do tego kupiony za 4zł transoptor szczelinowy. W sumie dało mi to ok 150 impulsów na jeden obrót koła. Niezbyt wiele, ale narazie starczy. Nie bawię się narazie detekcją kierunku obrotu, jedynie prędkością.
    Jeden enk. podpięty jest pod przerwanie, a drugi pod timera (niestety został mi wolny tylko 1 w uC). Wszystko ładnie działa i nadąża. :-)
    Po napisaniu małego programiku udało mi się 'zmusić' robota do tego, aby korygował prędkość jazdy tak aby poruszać sie prosto. Program będę rozwijać nadal.
    Wkrótce, jeśli mi się uda, zaprezentuję moją konstrukcję. Działa już transmisja szeregowa z kompem, niedługo dalsze bajery :D

    0
  • #9 29 Gru 2007 23:46
    m_michael
    Poziom 10  

    mam pytanie.. czy mógłbyś udostępnić schemat podłączenia tego Twojego transoptora szczelinowego z mikrokontrolerem? i ew. program? pisałeś to może w C? :) z góry dzięki za pomoc. takiego właśnie chyba rozwiązania poszukuję od dłuższego czasu, zwłaszcza że moje modele - robociki są tylko z lego :)

    0