Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2603
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    191

Wszystko napisane przez Elvis

  1. Moj pierwszy robot (no może nibyrobot) to był przerobiony zdalnie sterowany samochodzik. Ale nic mądrego w kwestii sterowania nie udało mi się zrobić, lightfollower był z niego baaardzo kulawy. Więc tego typu konstrukcje porzuciłem i nie zamierzam wracać. Chyba ciężko takie coś oprogramować.
  2. Mosfet-y to akurat nic skomplikowanego. Moim zdaniem trudniej zrozumieć zwykłe tranzystory bipolarne. Jest tylko jeden problem z mosfetami - są ich 4 rodzaje. Wszystkie mają 3 wyprowadzenia, oznaczane S (source), G (gate), D (drain). Tranzystor z kanałem wzbogacanym typu N ma symbol: Podłączamy taki tranzystor następująco: do S podłączamy masę, do D silnik (drugie wyjście silnika do zasilania), G łączymy z procesorem (najlepiej przez nieduży rezystor, można dać 100Ohm). Gdy procesor wystawia na pin 0, na wejściu G jest zerowe napięcie, a między pinami D i S nie płynie prąd. Po wystawieniu 1 na pin procesora, między G i S pojawi się napięcie ok. 5V. Tranzystor zacznie przewodzić i między pinami D i S (czyli przez silnik) popłynie prąd. Podsumowując: przez tranzystor płynie prąd jeśli na wejściu G podamy napięcie. Działa jak zwykły przekaźnik.
  3. Radiowa transmisja danych, czyli robot zdalnie sterowany (Wstęp) Artykuł ten powstanie w kilku częściach, prawdopodobnie czterech, ale nigdy nic nie wiadomo. W kolejnych częściach planuję opisać różne możliwości bezprzewodowej transmisji danych między urządzeniami (np. robotami). Od razu uprzedzam, nie będę się zajmował ani Wi-Fi, ani Bluetooth. Jeśli kogoś stać na drogie moduły, ma możliwość używania TCP/IP, ten artykuł może przeczytać tylko po to, aby zobaczyć jak wiele problemów go ominęło. Moim celem jest znalezienie taniego modułu, za pomocą którego możliwe będzie przesyłanie informacji między układami. Jako przykład zastosowania niech posłuży robot. Pewnie każdy wymyśli wiele ciekawszych zastosowań komunikacji radiowej. Moje pomysły to: zdalne sterowanie robotem (proszę się nie śmiać, na początek zawsze coś) zdalne debugowanie pracy robota – czasem się przydaje zbieranie informacji, np. o otoczeniu robota wymiana informacji między robotami Wracając jednak na ziemię, wypada najpierw sprawdzić, co można kupić za rozsądną cenę. Postanowiłem zastosować gotowe moduły RF, ich wybór podyktowany był ceną oraz dostępnością: 1.HM-T868S, HM-R868S 2.RFM12B / 868D 3.CC1000PP-433 Pierwsza para modułów zapewnia tylko jednokierunkową komunikację (simpleks). Moduł HM-T868S jest nadajnikiem, HM-R868S to odbiornik. Nie ma możliwości przesyłania danych w przeciwnym kierunku. Jednak cena modułów sprawia, że rozwiązanie jest warte przemyślenia. Ceny z TME (www.tme.pl): HM-T868S – 12,13zł HM-R868S – 16,96zł Dodatkowym atutem jest bardzo prosty interfejs sterowania modułami, ale o tym dalej. Kolejnym kandydatem na idealny moduł jest RFM12B/868D. Jego cena (również TME) wynosi: 22,94 zł. Nieco więcej niż poprzednio, ale ten moduł może pracować zarówno jako nadajnik jak lub odbiornik. Trzecim i ostatnim opisywanym modułem jest CC1000PP-433. Dostępny jest na stronie www.mikroprocesor.pl, a jego cena wynosi 46,36zł. Platforma testowa Aby przetestować moduły niezbędne nam będą co najmniej dwa urządzenia, które będą się ze sobą komunikować. Do testów wykorzystałem dwie identyczne płytki (zaprojektowane pod moduł CC1000PP-433, ale pozostałe powinno być łatwiej podłączyć). Płytki testowe wyposażone są w procesor Atmega8L – wynika to z konieczności zasilania modułów napięciem 3.3V (szczegóły w dalszej części). Każda z płytek posiada 3 switch-e oraz 3 diody. Najprostsza wersja sterowania to zapalanie diody po naciśnięciu przycisku (na przeciwnym układzie oczywiście). Dodatkowo układy mają wyprowadzone piny od UART-a, więc istnieje możliwość podłączenia płytek do portu szeregowego komputera przez układ typu max232. Stosuję takie rozwiązanie, aby nieco zaoszczędzić, układ max232 mam na oddzielnej płytce, a testową traktuję jako jednorazową. Radiowa transmisja danych, czyli robot zdalnie sterowany cz.2 (moduły HM-T868S i HM-R868S) Testowany zestaw składa się z modułu nadajnika HM-T868S oraz odbiornika HM-R868S. Pierwszym zaskoczeniem jest wielkość modułów, są bardzo małe. W komplecie dostajemy do nich odpowiednio przycięte przewody, służące jako anteny. Kolejne zaskoczenie do liczba wyprowadzeń - nadajnik ma tylko 3 piny, odbiornik 4. Piny są rozmieszczone standardowo, co 2,54mm, więc bez problemu można moduły wpiąć do płytki testowej. Więcej informacji o modułach jest na stronie producenta: http://www.hoperf.com/ Piny nadajnika to: GND, DATA, VCC. Odbiornika: GND, DATA, VCC, ENABLE. Rozszyfrowanie oznaczeń nie sprawia problemów, jednak lepiej zapoznać się z krótkim datasheetem ze strony producenta. Moduły powinny być zasilane napięciem 3V, jednak mogą pracować do 5,4V, więc podłączenie do AVR-a nie sprawi problemu. Pin ENABLE odbiornika pozwala na wyłączenie modułu, gdy nie jest używany. Podanie na nim napięcia VCC uruchamia odbiornik. Nadajnik sam wykrywa brak danych i przechodzi w tryb uśpienia. Okazuje się, że moduł jest maksymalnie prosty w obsłudze. Nie zapewnia żadnego protokołu komunikacji, to co podamy na pin DATA nadajnika zostanie wysłane i pojawi się na pinie DATA odbiornika. Prosty test polegający na podłączeniu generatora do nadajnika i oscyloskopu do odbiornika potwierdza taki właśnie sposób działania modułów. Prędkość transmisji zalecana przez producenta to 4800bps, maksimum 9600, co w dzisiejszych czasach nie oszałamia. Przy częstotliwości w okolicach 10kHz widoczne jest zniekształcenie sygnału, więc lepiej nie liczyć na maksymalną prędkość transmisji. Prostota obsługi modułów ma swoje wady. Trzeba samemu obsłużyć protokół transmisji. Ja postanowiłem wykorzystać sprzętowy UART procesoraś. Nadajnik połączyłem więc do pinu TXD w płytce nadajnika, odbiornik do pinu RXD płytki odbiornika. Pozostało dodać podciąg pinu ENABLE w odbiorniku (niech pracuje cały czas, nie oszczędzam prądu podczas testów) i podłączyć zasilanie. W datasheecie producent sugeruje, aby pin ENABLE był nieaktywny podczas podłączania zasilania i aktywowany później. Okazało się to o tyle istotne, że inaczej odbiornik nie zawsze „wstaje”. Problem nie był duży – wystarczy podłączyć ENABLE do pinu procesora i programowo wystawiać 1 chwilę po uruchomieniu układu. W poprzedniej części opisałem z czego składają się moje płytki testowe, teraz zamieszczam więcej informacji o nich. Na schemacie jest procesor Atmega8, jednak użyłem Atmega8L – ze względu na zasilanie z 3V (będzie niezbędne dla modułu CC1000, o tym później). Gniazdo RS232 to wyprowadzenia UART-a wraz z zasilaniem, P1 i P2 to gniazdo do podłączenia CC1000. Poza tym jest oczywiście gniazdo programatora, 3 diody i 3 switche do sterowania układem oraz stabilizator 3.3V. Do obecnych testów można użyć uproszczonej wersji układu, przede wszystkim można użyć Attiny, ale miałem akurat atmege8, więc wykorzystałem co było pod ręką. Obecne testy przeprowadzałem na 5V (stabilizatory zalutuję później), więc zasilanie też można uprościć. Jedno o czym warto pamiętać to dodanie rezonatora. Ja używam rezonatorów 4MHz. Próbowałem najpierw działać bez nich, niestety układy nie mogły się komunikować poprawnie. Wystarczył upalny dzień i generator RC jednego z układów przestawił się na tyle, że dane po RS232 nie były poprawne. Rezonator zapewnia dużo większą dokładność zegarów. Program testowy Pierwszą czynnością jest konfiguracja modułu UART do pracy. Ustawiłem prędkość na 2400bps. Piny od przełączników ustawiane są jako wejścia, piny od diód jako wyjścia. Pętla główna odczytuje stan przełączników, jeśli któryś zostanie przyciśnięty, wysyła kod przycisku. Kodowanie jest bardzo proste i bazuje na znakach: 'A' – wciśnięty przycisk 1, 'B' – przycisk 2, 'C' – przycisk 3 Moduł odbiornika działa na przerwaniu i po odebraniu bajtu steruje diodami. 'A' – zapala diodę 1, 'B' – 2, 'C' -3 Są też kody gaszenia diód: 'a' – gasi diodę 1, 'b' – 2, 'c' – 3 Zarówno płytka nadajnika jak i odbiornika pracują na tym samym programie. Do testów wystarczy założyć zworkę na piny RXD i TXD – wtedy moduł komunikuje się sam ze sobą, naciskanie przycisków zapala odpowiednie diody. Moduły podłączyłem następująco: Nadajnik GND – do pinu 1 (GND) gniazda JP4 (RS232) DATA – do pinu 2 (TXD) gniazda JP4 (RS232) VCC – do pinu 4 (VDD) gniazda JP4 (RS232) Odbiornik GND – do pinu 1 (GND) gniazda JP4 (RS232) DATA – do pinu 3 (RXD) gniazda JP4 (RS232) VCC – do pinu 4 (VDD) gniazda JP4 (RS232) ENABLE – podciąg rezystorem do pinu VCC Po sprawdzeniu połączeń i podłączeniu zasilania spotkało mnie pierwsze rozczarowanie. Odbiornik odbiera straszne ilości „śmieci”. Natomiast dane z nadajnika lubią się „gubić”. Aby poprawić działanie układu zmieniłem program: 1)po naciśnięciu przycisku program cyklicznie wysyła kod zapalania diody 2)gdy przyciski są zwolnione ciągle wysyła kody gaszenia diód Takie zmiany pomogły – program działa bardzo ładnie. Niestety śmieci, nadal pojawiają się na odbiorniku. Należałoby dodać filtrowanie danych w odbiorniku, jednak na potrzeby sterowania diodami program działa bardzo ładnie. Testy pozwalają na podsumowanie, jakie są plusy i minusy układu: Zalety: 1)Niska cena 2)Prostota działania (nawet procesor nie jest niezbędny, można zrobić radiowy włącznik, czy czujnik bez procesora) 3)Łatwe podłączenie 4)Możliwa praca z 5V Wady: 1)Brak jakiegokolwiek protokołu transmisji 2)Zaśmiecony sygnał na odbiorniku 3)Konieczność wielokrotnego wysłania danych Podsumowując układ dobrze nadaje się dla początkujących elektroników, którzy nie chcą zajmować się programowaniem obsługi skomplikowanego układu. Za jego pomocą można łatwo wykonać układ zdalnego sterowania np. robota. Można też odczytywać stan czujników lub urządzeń, np. mierzyć temperaturę w innym pokoju.
  4. Przyznaję, że z silnikami DC nie mam za dużo doświadczeń, stąd ostrożność Natomiast używałem L298 do sterowania silnikami krokowymi, i wiem, że krokowy potrafi sporo wyindukować przy sterowaniu z PWM.
  5. Nie wiem jaki silnik chcesz podłączyć, ale jeśli używasz L298 zamiast L293 to zakładam, że silnik bierze większy prąd. A skoro większy prąd, to nie oszczędzaj na diodach. Ja proponowałbym np. SR240 (dostępne w TME). 1n5817 są marne z 2 powodów: tylko 1A i tylko 20V
  6. Ja zrozumiałem, że prąd poszedł na płytę. Ale może racja, że tylko programator ucierpiał. Szkoda, bo myślałem, że będzie można porównać wytrzymałość AVR i PIC.
  7. Ciekawe, czy procesor przeżył. Ja zrobiłem taki numer z PIC-em i chociaż zadymiło się z niego, a na obudowie został ślad po stopieniu, procesor dalej działa. Pytanie czy AVR też może przeżyć taki wypadek.
  8. Co do przejściówki USB<->PS/2 to nie wiem na jakiej zasadzie to działa, ale to ciekawy offtopic. Może ktoś to kiedyś analizował? Bo chociaż elektrycznie przejściówka to nic wielkiego, to jednak protokół USB jest dużo bardziej skomplikowany niż PS/2. Ciekawe na jakiej zasadzie następuje wybór protokołów. [ Dodano: 04 Sie 09 07:26 ] Jak chodzi o led-a, to sprawdzę wieczorem czy oświetlenie podłoża da lepsze rezultaty. Obawiam się jednak, że nie pomoże. W myszce, pod sensorem znajdują się 2 soczewki. Pierwsza jest przy sensorze, druga przy ledzie. Wygląda na to że sam sensor nie widziałby podłoża prawidłowo - wymaga soczewki (w datasheecie piszą o tej soczewce). Z drugiej strony soczewka prawdopodobnie ogniskuje na określoną odległość. Soczewka przy ledzie pewnie nie jest konieczna, ale przez nią trudniej zamontować leda pionowo. [ Dodano: 04 Sie 09 08:38 ] Niestety pomimo wielu prób poprawy podświetlenia, nie udało mi się uzyskać układu działającego na odległość. Może komuś uda się to lepiej, ale według mnie sensor działa, tylko dociśnięty do podłoża. Czyli tak jak typowa myszka.
  9. PS/2 jest łatwo dekodować, trudniej byłoby w przypadku myszki po USB. Ale moim celem nie było używanie całej myszy w robocie. Chciałem sprawdzić, czy ma sens wylutowanie sensora z myszki i użycie we własnym projekcie. Po eksperymentach widzę, że największy problem to część mechaniczna. Soczewkę i czujnik trzeba bardzo dokładnie umieścić - najprościej wykorzystać kawałek obudowy myszki. Spostrzeżeniami postanowiłem się podzielić i stąd ten artykuł
  10. Wydawało mi się, że opis jest czytelny. Przeróbka była bardzo prosta. Pewnie inne myszki będą miały w innych miejscach podłączenia, więc nie piszę co gdzie jest na płytce. Każdy powinien szybko zorientować się co i jak. 1) podłączyłem GND płytki ewaluacyjnej do GND myszki (pin 6 układu PAW3101DB) 2) zasilanie 5V podłączone do zasilania myszy (pin 7) 3) wolny pin IO z płytki (wybrałem PG0) podłączyłem do SCLK (pin 4) 4) kolejny wolny pin IO (u mnie PG1) podłączyłęm do SDIO (pin 3) Jedynie pkt.4 był ciekawy, pozostałe to proste podłączenie przewodów. Na płytce pompy linia SDIO była połączona przez rezystor 100Ohm. Dzięki temu podczas przełączania wysyłanie/odbieranie danych nie występuje zwarcie. Więc podłączyłem płytkę przez ten rezystor. Pozostało jeszcze odłączyć układ który był w oryginalnej myszce - wystarczyło przeciąć ścieżki od SDIO i SCLK do niego.
  11. W niniejszym artykule chciałbym opisać eksperyment z użyciem czytnika z myszki optycznej. Jak chyba każdy początkujący fan robotyki po zmontowaniu pierwszego, prostego robota zacząłem zastanawiać się, co do niego można dodać. W wielu postach pojawia się podobne pytanie: jak odczytać położenie robota. Informację o otoczeniu można zbierać na wiele sposobów, jednak jeśli chcemy zbudować robota, który potrafi uczyć się otocznia, niezbędne jest określenie jego pozycji. Szukając sposobu pomiaru przebytej drogi brałem pod uwagę różne możliwości. Najbardziej chyba oczywiste było zastosowanie enkoderów. Niestety pomiar który zapewniają jest jedynie pośredni. Poślizg, czy zablokowanie kół robota niweczy trud włożony w zastosowanie enkoderów. Poza tym każdy kto ma jakieś doświadczenie z enkoderami zapewne wie, że niełatwo się ich używa. Wśród różnych rozwiązań trafiłem na jedno, bardzo obiecujące. We właściwie każdej, obecnie sprzedawanej myszce optycznej znajduje się czytnik przesunięcia. Ma on postać kamery oraz procesora DSP analizującego przesunięcie obrazu (a więc i ruch myszki). Postanowiłem sprawdzić, jak taki czytnik sprawdza się w praktyce. W najbliższym sklepie kupiłem najtańszą myszkę, którą akurat mieli. Dokładniejszy jej opis jest na stronie sklepu: http://www.komputronik.pl/index.php/product/34671/Peryferia/Myszki-i-Klawiatury/A4-TECH_SWOP-3_czarna_2_x_click.html Myszka wyposażona była w łącze PS/2. Po rozkręceniu okazało się, że oparta jest na układzie PAW3101DB. Dokładny opis układu jest pod adresem: http://www.pixart.com.tw/upload/PAW3101DB_SPEC_V31_20081009154102.pdf Udało się przy okazji wylutować kilka switchy oraz impulsator (całkiem przyzwoity). Po analizie datasheeta i układu płytki okazało się, że do eksperymentów można wykorzystać płytkę myszki, nie trzeba nawet wylutowywać układu detektora. Wylutowywanie okazało się z resztą, całkiem sporym wyzwaniem. Myszka jest wykonana lutem bezołowiowym, więc wymontowanie elementów to niemały wysiłek. Po wstępnej analizie ustaliłem, że: * elektronika myszki zasilana jest z 5V (więc idealnie dla AVR-ów) * wystarczy przeciąć 1 ścieżkę i 1 zworkę, aby podłączyć przewody do komunikacji z sensorem Do celów eksperymentalnych wykorzystałem płytkę ewaluacyjną (więcej info na stronie: http://www.shop.kristech.eu/product_info.php?cPath=22_41&products_id=64). Połączenie między elektroniką myszki i płytki ewaluacyjnej wykonałem za pomocą 4-żyłowego przewodu. Wykorzystane linie: 1) GND - masa 2) 5V - zasilanie 3) SCLK - linia zegarowa, generatorem jest procesor 4) SDIO - linia danych, do transmisji w obu kierunkach Po sprawdzeniu poprawności połączeń i podłączeniu zasilania nastąpił czas na przygotowanie softu. Metoda komunikacji okazała się bardzo prosta. Sensor wyposażony jest w ponumerowane rejestry, do każdego możemy zapisać lub odczytać 8-bitową wartość. W praktyce do pracy wystarczą 3 rejestry: Rejestr 0x16 - z niego odczytujemy flagę, czy w kolejnych rejestrach są gotowe dane Rejestr 0x17 - przesunięcie X Rejestr 0x18 - przesunięcie Y W rejestrze 0x16 wystarczy sprawdzić najwyższy bit. Jeśli jest 1, to wykonujemy odczyt przesunięcia. Rejestry 0x17 i 0x18 przechowują przesunięcie, jako 8-bitowe liczby ze znakiem. Kod służący do odczytania przesunięcia wygląda wiec następująco: byte = mouse_read_reg(0x16); if (byte & 0x80) { dx = mouse_read_reg(0x17); dy = mouse_read_reg(0x18); x += dx; y += dy; } Otrzymane wyniki są w jednostkach domyślnych pracy sensora. Ponieważ ma on rozdzielczość 800dpi, więc jednostką jest 1/800 cala. Pozostała część programu to przeliczanie wyników na mm i wyświetlanie na LCD. Rezultat okazał się bardzo interesujący, wyniki są dokładne, ale niestety dał znać o sobie istotny mankament rozwiązania: Czujnik musi być umieszczony w odpowiedniej odległości od podłoża, nawet minimalna zmiana odległości uniemożliwia odczyt. Na szczęście nie wyrzuciłem obudowy myszki, więc testy wykonywałem po umieszczeniu elektroniki w resztkach obudowy. Nie wiem jak układ spisywałby się w gotowym robocie. Zagwarantowanie dokładnego przylegania czujnika do podłoża może być trudne. Z drugiej strony czujnik pozwala na łatwe i tanie odczytanie położenia (właściwie przemieszczenia) robota. Jest jeszcze jeden mały problem. Odczyty przesunięć muszą być wykonywane bardzo często. Rejestry przesunięć nie są buforowane, więc jeśli nie odczytamy danych na czas stracimy je. Nie analizowałem jeszcze jak często dane z sensora spływają, ale może okazać się konieczne dodanie oddzielnego procesora do odczytywania danych z sensora. Jednak mała płyteczka z atmega8 jest o wiele łatwiejsza do realizacji niż przygotowanie części mechanicznej. Zalety rozwiązania: * działa, i to bardzo dokładnie * jest łatwe w implementacji i tanie * daje rezultaty lepsze niż typowy enkoder * odczytuje przesunięcia poprzeczne i wymuszone np. zderzeniem Wady: * wymaga bardzo precyzyjnego umocowania względem podłoża * nie na każdym podłożu odczytuje przemieszczenie (jak myszka optyczna) * wymaga bardzo częstych odczytów danych (najlepiej dodatkowego procesora) MouseMove.c
  12. Drugi link nie działa, więc ciężko mi powiedzieć jak podłączyć serwo, przydałyby się opis sterownika. Natomiast co do LCD to możesz podłączyć pod dowolny port którego nie wykorzystujesz (tutaj niezbędny jest schemat płyty prototypowej, jak podeślesz, postaram się podpowiedzieć). Jedyne co ważne to linie danych podłącz do jednego portu, inaczej będzie dużo roboty programowo - chociaż i to się da zrobić.
  13. Więcej już głowy nie zawracam, ale jeszcze jedna możliwość. Podłączyłeś do B.1 i B.2, czyli Timer1. Timer1 jest 16-bitowy, więc max. wartość pwm może być inna niż 255.
  14. Dopiero teraz przeczytałem edycję posta. Wygląda mi na problem z indukcją silnika. Na pewno masz ukłąd L293D - chodzi o D ? Bo inne wersje nie mają diód i trzeba dodać na zewnątrz. Na próbę możesz takie diody dodać, najlepiej schotky. Kiedyś miałem podobny problem z silnikiem krokowym i sterowaniem przez MOSFETa. Indukowało się ponad 100V.
  15. Właśnie podłączyłem u mnie L293D. Działa bez problemu. Co prawda przy zasilaniu 5V na silniku jest tylko 3,7V, ale to już urok tego układu. Na razie nie używałem PWM-a, na piny EN dałem 1, na 3A->0, 4A->1 i silnik się kręci. W moim układzie nie dałem kondensatorów, ale one raczej pomogą, niż zaszkodzą. Sprawdź miernikiem piny układu L293, czy są napięcia jak powinny, zobacz, czy nie masz gdzieś zwarcia. Poza tym nie mam pomysłu dlaczego nie działa.
  16. Sprawdź, czy dobrze wysterowałeś piny 1A, 2A, itd. (portb.0, portd.7). Poza tym może być zwykły błąd w połączeniach - odłącz silniki i zobacz, czy L293 się nie grzeje. Ja planuję dzisiaj wieczorem uruchamiać ukłąd na L293, schemat podłączenia właściwie identyczny, więc zobaczę co się u mnie będzie działo.
  17. Temat jakby umarł. Trochę szkoda bo zbudowanie sonaru to bardzo ciekawa sprawa. Z moich doświadczeń mogę powiedzieć, że schemat wklejony przez nes86 działa - jest to kit AVT-2822 (odbiornik 100% skopiowany, w nadajniku avt jest przetwornica). Po eksperymentach z kit-em planuję zrobić własny układ, wszelka pomoc mile widziana
×
×
  • Utwórz nowe...