Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją od 15.07.2006 w Posty

  1. 64 punktów
    Konstrukcja linefollowera jest oparta o laminat szklano-epoksydowy stanowiący jednocześnie płytkę drukowaną elektroniki. Konstrukcja przystosowana jest również do jeżdżenia po torach z przeszkodami. Robot posiada możliwość regulowania wysunięcia czujników linii, jak również wysokość czujników nad torem. Sterowany jest nowoczesnym mikrokontrolerem ATXmega128A1. Silniki pozwalają robotowi osiągać prędkości ponad 1,5m/s co stawia go w czołówce najszybszych polskich robotów typu Lf. Oryginalny design wraz z efektami świetlnymi powoduje, że robot świetnie się prezentuje na torze. Przedstawiam robota klasy Linefollower, którego wykonałem razem z TIMONKiem. Jak wszystkie moje konstrukcje robot po ustaleniu koncepcji i wszystkich założeń konstrukcji został zaprojektowany w programie Autodesk Inventor. Oto kilka renderów z Inventora a w załączniku plik złożeniowy wraz ze wszystkimi plikami. Dla tych co mają inną wersję Inventora lub używają innego programu załączam również plik .step: Elektronika robota składa się z dwóch płytek drukowanych i wyświetlacza. Obwody drukowane zostały zaprojektowane w programie Altium Designer. Poniżej kilka zrzutów ekranu. W załączniku dołączam schematy w formacie PDF oraz pliki Altiuma. Widok 3D płytki nie będzie działał, ponieważ projekt jest powiązany na stałe z plikami inventora. Po ominięciu kilku wyskakujących błędów powinien działać widok 2D obwodu. Kilka zdań o konstrukcji mechanicznej: Jak widać na zdjęciach robot składa się z dwóch płytek drukowanych, dzięki czemu możliwa jest regulacja odległości czujników od osi napędowej. Możemy w ten sposób ustalić empirycznie optymalną odległość między osią kół a czujnikami. Z naszych obserwacji wynika, że robot, który ma większą odległość czujników od kół lepiej sprawdza się na szybszych trasach, które mają łagodniejsze zakręty. Płytki są ze sobą połączone przy pomocy 20 żyłowej taśmy. Środek ciężkości robota został umieszczony w miarę nisko nad ziemią, ok. 6mm oraz w odległości około 14mm przed osią kół. Cała konstrukcja waży ok. 100g (dokładną wagę podam w przyszłym tygodniu). W Linefollowerze zostały zastosowane silniki z Pololu w wersji HP z przekładnią 30:1, ich specyfikacja dostępna jest tutaj: http://www.pololu.com/catalog/product/1093. Silniki zostały zamocowane na podstawkach wyciętych laserowo z plexi, tak aby środek ciężkości znajdował się jak najniżej i aby płytka z elektroniką była umieszczona równolegle do podłoża. Kulka podpierająca przód robota również została kupiona w sklepie Pololu. Zastosowane koła to kółka z mobot.pl po mojej małej przeróbce. Do robota pasują również koła z Pololu, które widać na niektórych filmikach i zdjęciach. Słów parę o elektronice: Na przedniej płytce znajduje się 16 transoptorów odbiciowych KTIR0711S, 4 diody LED, czujnik Sharp gp2y0d340k wraz z niezbędnymi elementami (filtr LC na zasilaniu, dzielnik rezystorowy na wyjściu oraz zworka do włączania czujnika), dwa kondensatory odsprzęgające napięcia +3,3V i +5V oraz 20-pinowe złącze taśmy. Na tylnej płytce: -układ zasilania złożony z dwóch połączonych kaskadowo stabilizatorów L7805ACDT (+5V) i LF33 (+3,3V). Przed stabilizatorami znajduje się dodatkowo włącznik i dioda prostownicza FR3 zabezpieczająca przed odwrotnym podłączeniem akumulatora. Ze stabilizatorami współpracują kondensatory tantalowe SMD. -procesor ATXmega128A1 wraz z ośmioma kondensatorami odsprzedającymi i dwoma filtrami LC filtrującymi napięcie dołączone do nóżek AVcc. -dwa mostki H VNH3SP30 sterujące silnikami. -komparator sygnalizujący rozładowanie akumulatora poniżej 50% poprzez zapalenie zielonej (zielona aby się wyróżniała) diody LED. Na wejścia komparatora podane są przez dzielniki rezystorowe napięcia akumulatora i napięcie ze stabilizatora +3,3V. Dodatkowo wyjście komparatora zostało podłączone do jednego z wyprowadzeń mikrokontrolera, aby można było programowo zareagować na rozładowanie akumulatora. -6-pinowe złącze programatora „micromatch” (wykorzystane tylko 4 piny) -scalony odbiornik podczerwieni TSOP32156, do współpracy z pilotem -złącze wyświetlacza LCD, na które wyprowadzony został cały port F (na schemacie jest narysowane tylko 7 linii, ale na płytce można podłączyć 8 linię robiąc małą zworkę z cyny), dzięki czemu złącze te może być wykorzystane również do rozbudowy robota. -trzy microswitche -3 czerwone diody sygnalizujące poprawne pojawienie się w układzie napięć: akumulatora, +5V, +3,3V. -dwie diody LED SMD RGB wraz z tranzystorami sterującymi. Diody zostały zamontowane od spodu robota i mają za zadanie oświetlanie toru (efekt wizualny). Tranzystory sterowane są sześcioma sygnałami PWM, dzięki czemu na diodach można uzyskać dowolny kolor bez obciążania procesora. -18 sztuk czerwonych diod LED SMD 0603, służących do generowania efektów wizualnych -20-pinowe złącze taśmy łączącej obie płytki Trasa: Trasa dla robota wykonana została z laminowanej płyty paździerzowej zakupionej w Castoramie. Płyta została pocięta na kawałki ok. 1x1m, a następnie skręcona przy pomocy stalowych płaskowników. Boki pociętej płyty zabezpieczyliśmy tzw. obrzeżami meblowymi. Linia po której jeździć ma robot wyklejona została izolacją o szerokości 19mm. Bandy toru wykonane zostały z samoprzylepnych klinów z gąbki. Filmiki z pierwszych testów: Drugie testy: Robot nie jeździ jeszcze z maksymalną prędkością, widać jak czasami wariuje na łączeniach płyt. Oprogramowanie jest cały czas rozwijane więc z czasem będzie jeździł szybciej. Ta odstająca do góry taśma jest tylko tymczasowo, później będzie założona taśma na wymiar. OSIĄGNIĘCIA: Inferno wraz z bratem bliźniakiem Mefisto wziął udział w zawodach LF i LF z przeszkodami na SumoChallenge w Łodzi oraz w zawodach LF na RoboticArena we Wrocławiu osiągając: Sumochallenge2010: 1. miejsce dla robota Mefisto w kategorii Linefollower. 2. miejsce dla robota Inferno w kategorii Linefollower. 1. miejsce dla robota Inferno w kategorii Linefollower z przeszkodami. 3. miejsce dla robota Mefisto w kategorii Linefollower z przeszkodami. Film z eliminacji na SumoChallenge: RoboticArena2010: 1. miejsce dla robota Inferno w kategorii Linefollower. Podsumowując: mój i TIMONKa debiut w kategorii Linefollowerów uznajemy za udany Film nagrany podczas dni otwartych Politechniki Poznańskiej 27 listopada: schematy.rar LF.rar LF.rar robot.rar
  2. 43 punktów
    Kurs BASCOM - lekcja1-wstęp Kurs BASCOM - lekcja2 - pierwsze kroki Kurs BASCOM - lekcja3 - zaczynamy programować Kurs BASCOMZ powodu dużego zapotrzebowania na kurs programowania w języku ms basic postanowiłem napisać ciąg artykułów uczących podstaw programowania w tym właśnie języku. Artów będzie 3 lub 4 w zależności od tego jak podzielę materiał i jakim wolnym czasem będę dysponował. Kurs będzie dotyczył rodziny µC AVR. Jak wiadomo nie licząc robotów beam to robotyka by nie istniała bez programowania. Wiec każdy robotyk musi umieć programować chociaż w najprostszym języku jakim jest ten właśnie opisywany przeze mnie. Tak więc „Alea iacta est”(kości zostały rzucone). Zacznę od potrzebnego sprzętu: Programator: Na sam początek powinniśmy się zaopatrzyć w programator (my będziemy używać programatora isp). Najprostszy to cztery oporniki wtyk lpt i kawałek kabelka: Ale warto jest zabezpieczyć port lpt przed zepsuciem i zbudować bądź kupić stk200 : Są też programatory na port rs232 (com): Jeśli nie masz w komputerze portu lpt ani com co teraz jest coraz szerzej spotykanym zjawiskiem (niestety te dwa ważne porty dla elektronika powoli odchodzą w zapomnienie) Są też programatory pod usb. Na przykład usbasp którego można zobaczyć na tej stronie. Ale jeśli nie czujesz się na siłach aby coś takiego zbudować kup sobie programator, taki jak stk200 można w znanym serwisie aukcyjnym kupić już za 15 zł. To są tylko niektóre z programatorów, jest jeszcze ich wiele. Te które wymieniłem wydaja mi się najlepsze ale mogę się mylić ponieważ nie za wszystkich korzystałem-oparłem się na opinii użytkowników. Procesor: Ja proponuje na sam początek attinny2313. Czemu? Ponieważ jest wystarczający na rozpoczęcie przygody z mikrokontrolerami, jeżeli twój pierwszy program nie zmieści się w jego pamięci to mówię Ci mistrzu. Nie potrzebuje kwarcu- może pracować na wewnętrznym oscylatorze. Moim zdaniem na kilka pierwszych programów jest aż za dobry. W związku z pojawiającymi się wątpliwościami (wcześniej wydawało mi się to oczywiste) dodaje, że wyprowadzenia procesora podłączamy do tak samo nazywających się wyprowadzeń programatora. Kompilator: Kompilatorem języka ms basic którego będziemy używać będzie BASCOM-AVR. Można go pobrać z tej strony Obsługa programu: Po zainstalowaniu i uruchomieniu programu pokaże nam się okno główne: 1.Pasek menu 2.Pasek narzędzi 3.Lista zdefiniowanych etykiet 4.Lista zdefiniowanych procedur 5.”Nawigacja”mikroklocka 6.Pasek stanu 7.Obszar edytora kodu Funkcje ikon paska narzędzi: - nowy program - otwórz - zapisz - zapisz w nowym pliku - drukuj - podgląd wydruku - wytnij - kopiuj - wklej - wstaw wcięcie zaznaczonego fragmentu tekstu - usuń wcięcie zaznaczonego fragmentu tekstu - wyszukaj tekst - sprawdź poprawność programu - kompiluj - raport z kompilacji - symulator - uruchom programator - emulator terminala - zeruj układ - pomoc - exit Paweł “Ikar” Stankiewicz PS: jak zauważycie błędy to dajcie znać
  3. 34 punktów
    Przedstawiamy naszego Line Followera o nazwie Impact. Projekt robota powstał w tegoroczne wakacje, a pierwszy start miał miejsce na zawodach Sumo Challenge 2011 w Łodzi. A teraz kilka słów o samej konstrukcji. Elektronika Robotem steruje mikrokontroler firmy Atmel z rodziny AVR ATmega128A . Rolę sterowników silników, podobnie jak w naszych poprzednich konstrukcjach pełnią dwukanałowe mostki H TB6612 . Po jednym mostku na jeden silnik (kanały zostały połączone w celu uzyskania większej wydajności prądowej). Silnikiem bezszczotkowym znajdującym się w napędzie tunelowym steruje gotowy moduł zakupiony w sklepie HK. Regulatorem napięcia jest układ przetwornicy step-down (ST1S10PHR) . Stabilizatory impulsowe charakteryzują się wyższą sprawnością niż ich liniowe odpowiedniki. Do wykrywania linii użyte zostały czujniki KTIR0711S (15 czujników ułożonym po okręgu oraz dwa wysunięte do przodu i dwa do tyłu po bokach). Analogowy sygnał z sensorów zamieniany jest na cyfrowy przy użyciu komparatorów LM339 następnie podawany na piny mikrokontrolera. Na płytce z czujnikami umieszczony został także czujnik odległości. Do komunikacji z modułem LCD oraz komputerem został wyprowadzony interfejs UART, który jest również złączem do programowania mikrokontrolera. Pozwoliło to zaoszczędzić miejsce na płytce oraz ilość wyprowadzeń mikrokontrolera. Drugi mikrokontroler wraz z odbiornikiem podczerwieni, służące do dekodowania sygnału z pilota (RC5) znajdują się na płytce, która tworzy most łączący czujniki z płyta główna. Zostało na niej także przewidziane miejsce na żyroskop. PCB wykonane w firmie Satland Prototype. Mechanika Konstrukcja oparta jest na laminacie, dodatkowo do łączenia czujników z płytką główną wykorzystane zostały listwy węglowe. Robot napędzany jest przez dwa silniki Pololu HP 10:1. W celu uzyskania dodatkowego docisku zastosowana została turbina z silnikiem bezszczotykowym - EDF27. Koła składają się z felg wytoczonych z poliamidu oraz opon Mini-Z. Płytka z czujnikami podparta została przez dwa Ball Castery 3/8". Konstrukcja wraz z baterią waży ok. 140g. Zasilanie i soft Całość zasilana jest z pakietu Li-Pol 2S 7,4V, jego poziom kontrolowany jest przez ADC oraz wyświetlany na LCD. Program został napisany w języku C. Do sterownia wykorzystywany jest algorytm PD. Regulator silnika bezszczotkowego obsługuje się w sposób bardzo podobny do obsługi serw modelarskich (f=50Hz, regulacja obrotów w zakresie 1-2 ms). Wszystkie ważne parametry są wyświetlane oraz ustawiane (zapisywane w pamięci EEPROM) przy pomocy modułu wyświetlacza LCD wyposażonego w 4 przyciski. Osiągnięcia 3. miejsce - Sumo Challenge 2011 Łódź - Line Follower 2. czas - Sumo Challenge 2011 Łódź - Line Follower z przeszkodami (poza konkurencją) 2. miejsce - ASTOR Robot Challenge - Line Follower 3. miejsce – Robotic Arena 2011 – Line Follower Zdjęcia Kilka zdjęć wykonanych z pomocą mikroskopu: Filmy https://www.youtube.com/watch?v=wydRW_vmjWUhttps://www.youtube.com/watch?v=RDJmhSkCdxc
  4. 26 punktów
    Rapid jest moją drugą konstrukcją micromouse. Zawiera ona kilka poprawek względem pierwszej (robot Wariat), z których najważniejszą jest użycie żyroskopu. Konstrukcja mechaniczna i zasilanie Robot zbudowany jest na płytce PCB, która stanowi jego podwozie. Założeniem projektu było uzyskanie nisko położonego środka cieżkości oraz jak najmniejszej masy. Dodatkowym atutem robota miała być jego mała szerokość, która pozwalałaby na poruszanie się po "skosie". Napędem robota są silniki Pololu 10:1 sterowane przez dwa mostki TB6612. Jako zasilanie wykorzystywane są akumulatory litowo-polimerowe o jak najmniejszym rozmiarze i niewielkiej masie. Z powodu małych pojemności konieczna jest częsta wymiana i ładowanie pakietów. W robocie używane są różne pakiety, różnych producentów. Mikrokontroler Sercem robota jest mikrokontroler STM32F405RGT6. O wyborze zdecydowała chęć nauki programowania mikrokontrolerów STM32 z najpotężniejszym rdzeniem Cortex-M4F oraz najmniejsza obudowa spośród wszystich procesorów rodziny STM32F4. Najważniejszymi cechami mikrokontrolera są: taktowanie 168MHz, 192kB RAM, 1MB flash, bardzo duża liczba timerów (m.in. ze sprzętową obsługą PWM oraz wyjść kwadraturowych enkoderów), wiele kanałów przetwornika ADC, DMA, sprzętowa obsługa liczb zmiennoprzecinkowych, wiele dostępnych interfejsów komunikacyjnych. Czujniki W robocie wykorzystano trzy rodzaje czujników: dalmierze optyczne, enkodery oraz żyroskop. Jako czujniki odległości wykorzystano diody SFH4511 oraz fototranzystory TEFT4300 (podłączenie takie samo jak w przypadku robota MIN7 autorstwa Ng Beng Kiat). Diody są sterowane impulsowo, każda z osobna. Wybranym żyroskopem jest analogowy czujnik ISZ-650 firmy Invensense. Jego zakres pomiarowy to +-2000st/s. O jego wyborze zdecydowała głównie dostępność i cena podczas zakupu. Podczas testów robota uszkodzono sensor, dlatego konieczna była wymiana. Zdecydowano się na moduł z żyroskopem L3GD20. Do podłączenia wykorzystano miejsce na wyświetlacz N3310 wraz z wyprowadzonym interfejsem SPI. Zamontowanie enkoderów obrotowych z magnesami na osiach silników powodowałoby poszerzenie całej konstrucji, więc zdecydowano się na użycie enkoderów liniowych wraz z odpowiednimi magnesami. Wykorzystane enkodery AS5304 oraz zamocowane magnesy na kołach robota przedstawiono na rysunkach poniżej. Użyte enkodery pozwalają uzyskać rozdzielczość 3520 impulsów na obrót koła, co daje w wyniku 0.028 mm/impuls. Interfejs użytkownika Założeniem projektu było wykorzystanie joysticka oraz wyświetlacza z telefonu Nokia 3310. Obecnie oprogramowanie nie zawiera obsługi wyświetlacza, dlatego nie jest on zamontowany. Do wyboru prostych komend służy joystick oraz zamontowany buzzer. Buzzer służy także jako powiadomienie o charakterystycznych sytuacjach w labiryncie, np. wykrycie ścianki, dojechanie do środka labiryntu. Oprogramowanie Program opiera się o cykliczne wywoływanie funkcji z częstotliwością 1kHz. W funkcji tej wykonywane są pomiary czujników, aktualizowana jest pozycja robota oraz wyliczane są wartości współczynnika wypełnienia PWM na silniki. Robot posiada trapezoidalny profil sterowania prędkością. Implementacja i zasada działania jest bardzo podobna jak w artykule [Programowanie] Sterowanie robotem mobilnym klasy (2,0). Przeszukiwanie robota odbywa się z użyciem algorytmu floodfill. Po znalezieniu środka labiryntu, robot rozpoczyna wyznaczanie najszybszej ścieżki. Do tego celu użyto zmodyfikowanego algorytmu floodfill, którego wagami jest czas przejazdu. Podsumowanie Robot Rapid zachowuje się w labiryncie dosyć stabilnie i przewidywalnie. Jest to bardzo ważna cecha, ponieważ pozwala na dalszą pracę nad konstrukcją oraz rozwijanie oprogramowania. Pomysłów na poprawienie działania robota jest wiele. Ograniczeniem jest jedynie poświęcony temu czas. Galeria Osiągnięcia I miejsce w kategorii Micromouse na zawodach Robotic Arena 2012 II miejsce w kategorii Micromouse na zawodach Robomaticon 2013 I miejsce w kategorii Micromouse na zawodach Trójmiejski Turniej Robotów 2013 I miejsce w kategorii Micromouse na zawodach ROBO~motion 2013
  5. 24 punktów
    Witam Chciałbym przedstawić wam robota Silver Shaft klasy line follower (nazywany też SS skrót powstał podczas bardziej luźnych rozmów na chacie ). Postęp prac można było śledzić w worklogu. Prace nad robotem zacząłem w sierpniu 2011 roku, później prace mocno spowolniły z powodu braku czasu. Od połowy lutego tego roku wziąłem się do pracy zrobiłem płytkę, którą już wcześniej zaprojektowałem, polutowałem, napisałem pierwszą wersję programu i przeprowadziłem pierwsze próby. W marcu wystartował w zawodach Robomaticon zajmując 13 miejsce, co i tak było sukcesem jak na 3 dni (a właściwie popołudnia) na napisanie programu od podstaw i przeprowadzenie pierwszych prób. Szczerze mówiąc robot zaczął przyzwoicie jeździć w dzień zawodów ok.2 w nocy . Od tego czasu wprowadziłem kilka modyfikacji, zarówno sprzętowych jak i programowych. Kończąc wstęp, przejdźmy do konkretów. SPECYFIKACJA Wymiary: 120x80x32mm Waga samego robota: 75g Waga robota z akumulatorkiem: 86g Średni pobór prądu logiki: 130mA Średni pobór prądu logiki bez czujników linii: 45mA Coś dla miłośników anaglifów: Proces lutowania: MECHANIKA Konstrukcja mechaniczna jest bardzo prosta i powiedziałbym typowa dla robotów tej klasy. Robot składa się z trzech płytek drukowanych, głównej, płytki z czujnikami linii i z cyfrowym dalmierzem. Płyta główna ma 1,5mm grubości, pozostałe są jednostronne i mają grubość 0,8mm. Płyta główna jest jednocześnie podwoziem robota. Wykonanie płytki głównej zajęło mi dużo czasu z powodu złych ustawień drukarki (Pierwsza płytka dwustronna na nowej drukarce). Po zmianie ustawień i zmarnowaniu 3 płytek wielkości robota, płyta główna wyszła idealnie, bez żadnych zerwanych ścieżek i tylko z jednym, w sumie nieistotnym zwarciem przy podświetleniu led, oraz przesunięciem między warstwami <0,5mm, które jak na trzecią dwuwarstwówkę było i tak niewielkie. Napęd robota stanowią dwa silniczki pololu HP z przekładnią 30:1 wraz ze standardowymi kołami 32mm. i mocowaniami, które swoją drogą były kompletnym niewypałem (łącznie złamały się 8 razy, za każdym razem w innym miejscu). Rolę podpory przodu stanowi plastikowa kulka 3/8 cala. MONTAŻ Płytka została pocynowana „mechaniczne”, własnej roboty pasta + tasiemka odsysająca + trochę cyny i wprawy. Większość elementów typu rezystory, czy kondensatory są w obudowach 0805, wyjątek stanowią 4 rezystory 330R ograniczające prąd diod Ir w transoptorach. Pierwotnie były tam rezystorki o mniejszej wartości, jednak z powodu grzania się KTIR’ów zostały wymienione, a jako, że nie miałem odpowiedniej ilości w 0805, zostały zastąpione większymi wersjami 1206. Całość polutowana grotówką. Płytka z czujnikami została zamontowana na stałe i trzyma się na listwie goldpin, która jednocześnie stanowi połączenie elektryczne między nią a płytą główną. ZASILANIE Całego robota zasila pakiet Li-Pol 2s zlutowany z dwóch pojedynczych ogniw 450mAh firmy Batimex. Tu chciałem zaznaczyć, że wiem o istnieniu pakietów 2s. Złożyłem je sam, ponieważ potrzebowałem pakietu o nietypowych wymiarach, a nie miałem czasu na zamawianie w HK. Logika zasilana ze stabilizatora LM1117 na 5V, silniki z przetwornicy ST1S10PHR ustawionej na 6V, lub bezpośrednio z pakietu (wybór zworką). W tylnej części płytki mieści się wyłącznik zasilania z sygnalizacją włączenia i układ pomiaru baterii z diodą led informującą o spadku napięcia poniżej ok.6,6v – wtedy to na wyjściu przetwornicy napięcie zaczyna spadać poniżej 6v. Akumulator starcza na ok. 15-20 min testów. ELEKTRONIKA Schemat i wzór pcb eksportowany z programu EAGLE. Mózgiem robota jest ATMega32 taktowana zegarem 16MHz. Rolę czujników linii stanowi 8 transoptorów odbiciowych KTIR0711S, odczyt na wbudowanym w atmege adc.Tu muszę zaznaczyć, że trafiłem na wadliwą sztukę KTIR’a miał lekko zdeformowane „szybki” pod diodą Ir i fototranzystorem, i dawał zawyżone wartości (ok. 150 więcej 10 bitowego adc) mała korekta w programie zniwelowała rozbieżności, niemniej uważam, że czujniki są świetne. Sterowanie silnikami odbywa się za pomocą mostka H TB6612 jeden na oba silniki. Pwm o częstotliwości trochę ponad 7Khz. Na przodzie robota znajduje się zamontowany stosunkowo niedawno dalmierz cyfrowy sharp 10 cm GP2Y0D810Z0F. Nie spotkałem się z nim w żadnym innym lf’ie. Przyznam, że wątpiłem w jego praktyczną użyteczność, okazało się jednak, że robot jest w stanie wyhamować z pełnej prędkości w ok. 2-3cm, a czujnik działa na tyle szybko, że mam jeszcze spory zapas przed przeszkodą. Czujnik może pełnić dwie funkcje (wybierane zworką). Chamowanie i wznowienie jazdy dopiero po usunięciu przeszkody, lub omijanie jej. Dzięki temu, robot może startować w konkurencji line follower z przeszkodami. Do komunikacji użytkownik – robot, zamontowane zostały dwie diody led, dwa przyciski, odbiornik Ir TSOP4836, oraz złącze 10 pinowe na którym poza wyprowadzeniem zasilania i spi do programowania jest I2C i uart, umożliwiające podpięcie dodatkowych modułów (w tej kwestii wypowiem się, gdy napiszę i opublikuje pewien artykuł ) PROGRAM Program napisany w Bascomie, na dzień dzisiejszy zawiera nieco ponad 600 linijek kodu i jest to 6 wersja programu, zajmuje 10% z 32KB pamięci Flash. Program można podzielić na dwie główne części: 1.Część odpowiedzialną za jazdę a.Sprawdzenie stanu dalmierza b.Odczyt analogowy z czujników linii c.Konwersja wartości analogowych na binarne d.Wyliczenie położenia linii metodą średniej e.Przekazanie uchybu regulatorom f.Naniesienie korekty pwm na silniki 2.Część serwisowa a.Wyłączenie podświetlenia, wprowadzenie mostka w stan stanby b.Wysłanie zapytania i oczekiwania na odpowiedź po uart z aplikacji PC c.W razie braku odpowiedzi, przejście do trybu konsolowego d.Oczekiwanie na id zmiennej i jej wartości e.Zapis nowej wartości zmiennej do pamięci Regulator Proporcjonalno Różniczkujący, z czego człon D wymaga jeszcze dopieszczenia. Pojawił się już w 2 wersji programu, jednak do niedawna bardziej przeszkadzał, niż pomagał, dlatego podczas większości testów był wyłączany. Aktualizacje w kolejnych wersjach: 1.-; 2.Dodanie regulatora D, trybu serwisowego, odliczania przed startem, 3.Naprawienie błędu uniemożliwiającego pokonanie kąta prostego, efekty led przy starcie i zatrzymywaniu 4.Dodanie obsługi dalmierza 5.okiełznanie D, dynamiczne omijanie przeszkód, 6.poprawa wydajności programu - uproszczenie liczenia uchybu, integracja z programem PC w planach: Ulepszenie D, rozwinięcie możliwości komunikacji z PC, płynne i łatwo regulowane omijanie przeszkód, optymalizacja kodu oraz coś o czym dowiecie się przy publikacji artykułu OSIĄGNIĘCIA 13 Miejsce na Robomaticonie 2012 w kategorii Line Follower. Kilka zdjęć i filmików z robotem. Silver Shaft na starszym bracie "drewnobocie" Ok godziny po pierwszej jeździe z czujnikami: 3 dni później: Jazda próbna na torze Robomaticonu w Warszawie: Jedna z ostatnich jazd: Tor w wersji z przeszkodami- przy drugim okrążeniu lekko zawadził o przeszkodę, ale wielkość łuku była podyktowana wielkościami pierwszej trasy, i jest "na styk": (nagrywał sosnus) PODZIĘKOWANIA Dziękuję wszystkim, którzy przedstawili sugestię i krytykę, w worklogu. W szczególności Sabre, oraz jego robotowi Tsubame, który był poniekąd inspiracją dla tego lf'a. Dziękuję osobom z chatu za pomoc w mniejszych problemach, np. grzanie się ktirów, czy problem z komunikacją po spi, przede wszystkim bobb'iemu i KD93. Dziękuję Turlaczowi za "troskę" i codzienne pytanie "jak tam SS?" Dziękuję Sosnusowi, za pomoc w teoretycznych aspektach dokładności liczenia uchybu, wspólne testowanie robota i zmian w programie, oraz mile spędzony weekend. Czekam na słowa krytyki, oceny i pytania. Dziękuję
  6. 24 punktów
    Przedstawiam wam moją konstrukcję linefollowera, oraz płytkę, która powstała jako uniwersalna płytka do różnych robotów. Zacznijmy od początku, płytka oparta jest na mikrokontrolerze z rodziny ATmega48/88/168/328, w moim przypadku są to dwa układy ATmega168/328P. Schemat nie różni się bardzo od schematu Psotka3, zmiany jakie widać na pierwszy rzut oka to złącze 10-cio pinowe służące do podłączenia do 8 czujników, gotowe źródło prądowe oparte na LM317 do zasilania diod IR w płytce czujników (połączenie szeregowe diod), trzy przyciski kątowe typu mikroswitch (wykorzystywane przy wprowadzaniu zmian prędkości i konfiguracji ustawień wzmocnień współczynników algorytmu PID poprzez złożone menu). Płytka została zaprojektowana pod kątem mieszczenia się w całości pod wyświetlaczem LCD 2x8 zgodnym z HD44780, niestety podczas projektowania powiększyłem płytkę o 2,5mm czego następstwem są nie pasujące piny od podświetlania wyświetlacza: Tak jak w Psotku3, tak i w tej płytce, złącze służące do programowania, jest jednocześnie złączem dla LCD w trybie 4-ro bitowego przesyłania danych (oczywiście poza pinem Reset). Doprowadzenie płytki do takiej postacie zajęło mi bardzo dużo czasu, z przerwami spędziłem nad nią ponad miesiąc, nie licząc małej wpadki z pinami od podświetlania, myślę, że nie był to stracony czas. Płytka została wykorzystana w pierwszej wersji Strider'a, okazało się jednak, że silniki z Psotka2 po założeniu kół o średnicy 66mm, są zbyt słabe do napędzania robota, dlatego też powstał Strider2: Szczegóły techniczne: procesor: Atmega328P@20MHz czujniki: 8 sztuk KTIR0711S, ustawione w kształt, który miał poprawiać wykrywanie kątów prostych: zasilanie: 2 akumulatorki li-pol 450mAh, 5V dla logiki pochodzi z układu LP2950 mostek H: 2 układy SI9986CY (dwa pełne mostki H) robot napędzany jest silnikami z pololu, przekładnia 30:1, 1000obr/min, wersja silnika HP sterowanie silników: 4 kanały PWM z procesora kod w całości napisany w Bascomie, łącznie z obsługą PID oraz 4 kanałów PWM robot zawiera wyświetlacz LCD 2x8, na którym są wyświetlane różne parametry, na płytce jest miejsce na odbiornik podczerwieni TSOP348 (w tej płytce odbiornik nie został użyty), 3 mikro switche kątowe używane do konfiguracji prędkości poprzez zaawansowane menu wymiary: rozstaw osi 124mm, szerokość przodu 90mm, długość 110mm z przodu zamontowane są 2 kulki teflonowe, wykonane własnoręcznie na wiertarce z pomocą scyzoryka, papieru ściernego, i ponad dwóch godzin pracy na kulkę wymiary płytki 60,3x30,3 [mmxmm] masa robota wraz z akumulatorkami - 120g Ponieważ najprostsze rozwiązania są najlepsze, nie umieszczałem nigdzie włącznika, ani żadnych uchwytów na akumulatorki (doskonale w tej roli sprawdza się zwykła gumka recepturka). Oto kilka zdjęć samej płytki, oraz fazy projektowania: Strider2 jest moim pierwszym linefollowerem, który przekroczył prędkość 1m/s podążając za linią. Niestety okazuje się, że zastosowane mostki są za słabe do tych silników, daje się również we znaki brak kondensatorów równolegle do silników oraz kondensatorów na zasilaniu mostków. Po przekroczeniu pewnej wartości PWM/prędkości restartuje się mikrokontroler, co kończy się zatrzymaniem na torze. Poniżej najszybszy przejazd Stridera2 podczas zawodów Robo3DVision w Gdańsku. Czas przejazdu 7,23s, który dał mi szóste miejsce w eliminacjach, niestety mój linefollower nie jechał jeszcze wtedy z pełnią swoich możliwości.
  7. 21 punktów
    Przedstawiam robota typu linefollower, którego razem z kolegą wykonaliśmy w ramach projektu "Roboty mobilne" na PWr. Cechą odróżniającą go od innych konstrukcji tego typu jest możliwość zapamiętywania trasy. Robot wykonuje pierwszy przejazd ze stosunkowo wolną prędkością i dla każdego punktu trasy oblicza maksymalną możliwą prędkość, która pozwoli na przejazd bez poślizgu. Wiedza ta jest używana w celu zoptymalizowania czasu przejazdu podczas drugiego pokonywania trasy. Sercem robota jest mikrokontroler STM32F103RBT6. Do napędu służą silniki Pololu 10:1 HP (przy okazji - są beznadziejne) wspomagane enkoderami AS5040. Do wykrywania linii przewidziano 12 czujników KTIR, przy czym aktualnie używanych jest 8 (resztę przyjarałem hotem podczas lutowania i nie działają ). Napięcie 3,3V dla logiki pochodzi z przetwornicy MCP16301, natomiast silniki są zasilane bezpośrednio z akumulatora poprzez mostek MC33932. Oprócz tego na płytce zainstalowany jest akcelerometr/żyroskop MPU6050 (aktualnie niewykorzystany), 4 ledy, 3 przyciski oraz wyprowadzone złącza UART i SPI (dla modułu radiowego NRF24L01). Algorytm sterowana obejmuje regulatory PID dla prawego i lewego koła oraz regulator PID dla rotacji. Wartość translacji jest ustalana na sztywno lub jest uzależniona od aktualnego położenia robota na trasie (w przypadku drugiego przejazdu). Jazda ze sztywno zadaną prędkością, zdaje się 1,8m/s Zapamiętywanie trasy (film zawiera lokowanie produktu) Jeśli chodzi o robota to jestem bardzo pozytywnie zaskoczony działaniem zapamiętywania trasy. Do zrobienia pozostało uwzględnianie przyspieszeń liniowych przy wyznaczaniu profilu przejazdu, gdyż aktualnie obliczane jest tylko przyspieszenie dośrodkowe. Głównym problemem przy konstrukcji robota były notorycznie palące się silniki. Dwa spaliły się całkowicie, w jednym wytarła się zębatka, a szczotki były wymieniane chyba z pięć razy. W następnych konstrukcjach mam zamiar używać tylko silników BLDC. edit: Schemat Layout płytki głownej bom.txt
  8. 19 punktów
    Infinitum to trzeci robot w mojej karierze i najlepszy jaki udało mi się zbudować do tej pory. Robot powstawał stosunkowo długo (ponieważ w tym roku matura), jednak najwięcej do zrobienia było przed RoboticArena 2011, gdy na PCB wkradł się błąd, który oczywiście został usunięty. Robot powstawał przy współpracy z firmą Woszym , która zajmuje się montażem obwodów drukowanych. Również pomogli w krytycznej sytuacji. Elektronika: Standardowo użyłem mikrokontrolera firmy atmel- Atmega16, mostki to dwa TB6612, stabilizator L7805 wersji SMD, za oczy robią cyfrowe Sharpy GP2Y0D340K, komparator LM339D oraz KTIR0711S plus pozostałe drobne elementy. Robota wyposażyłem w LCD 8x2- jednym się ten pomysł podobał, innym nie, ale ja jestem zadowolony bo spełnił swoją funkcję- można sprawdzić aktualny stan aku, ustawić PWM jak i zobaczyć, za ile zacznie się walka Program: Program powstał w środowisku eclipse, napisany został w C, którego się dopiero zacząłem uczyć, więc jest to pierwszy mój program w tym języku. Nie wiedziałem, że jest taki fajny. W robocie jest przewijane menu, które obsługuje się trzema przyciskami - jeden enter, a dwa pozostałem służą do przewijania. Żeby wyjść do głównego menu trzeba przytrzymać te dwa przyciski do przewijania przez 3s. Mechanika: Obudowa Infinitum została wcięta z aluminium i profesjonalnie polakierowana przez lakiernika. Po walkach odprysków praktycznie nie ma więc się postarał . Silniki to HP 50:1 z pololu. Robot na zawodach ważył około 375g. Podsumowanie: Jak wspominałem jestem z niego bardzo zadowolony-udało się wyjść z grupy na RA11! Dla ciekawych nazwa wzięła się stąd, że były roboty Inferno i Mefisto to stwierdziłem, że musi być coś anty(w Google translator można sprawdzić ). Konstrukcja ma tylko 3 minusy: przyczepność, ilość śrubek i umiejscowienie włącznika – przy następnych konstrukcjach zwrócę na to większą uwagę . Filmiki: Znajdują się tu niektóre z wygranych walk https://www.youtube.com/watch?v=uGfYsFS2aMw
  9. 17 punktów
    Przedstawiam Wam robota „Rush” klasy minisumo. Prace nad nim rozpocząłem w listopadzie w 2012r. i po ok. 5 miesiącach konstrukcja była gotowa. Pierwszym turniejem robota miał być Robomaticon, lecz z powodu awarii silnika nie mogłem wystartować. A teraz kilka słów o nim... Elektronika Całość elektroniki znajduje się na jednej płytce, która stanowi jednocześnie podstawę konstrukcji. Mózgiem robota jest procesor Atmega32 o taktowaniu zewnętrznym 16MHz. Jako czujnik przeciwnika wykorzystane zostały czujniki cyfrowe Sharp o zasięgu 40cm, ułożone w półokręgu, jeden patrzący w przód, dwa pod kątem 45° i 2 patrzące na boki. Do wykrywania linii służą cztery KTIRy, dwa z przodu i dwa z tyłu, podłączone do procesora przez komparator. Do zatrzymywania robota służy odbiornik TSOP. Sterowaniem silników zajmują się dwa mostki TB6612, po jednym na silnik. Robot zasilany jest z pakietu Li-pol 2S 700mAh. Płytka została wykonana w firmie Satland Prototype. Mechanika Podstawą konstrukcji jest płytka z elektroniką o grubości 1,5mm, do której przymocowane są silniki i metalowa obudowa. Robot napędzany jest dwoma silnikami Pololu HP 30:1. Koła składają się z felg wykonanych metodą druku 3D oraz opon odlanych z silikonu. Robot waży 470g. Program Program napisany został w bascomie. Robotem steruje regulator P. Osiągnięcia 3. miejsce – ROBO~motion 2013 Rzeszów Podsumowanie Ogólnie jestem zadowolony z konstrukcji, choć zawiera ona kilka niedociągnięć. Założenia zostały spełnione, nabrałem nowego doświadczenia, które na pewno przyda się przy budowie kolejnego robota. Zapraszam do zadawania pytań. Zdjęcia Filmiki (po więcej filmików zapraszam na kanał)
  10. 15 punktów
    Interfejs SPI używany jest do komunikacji między mikrokontrolerami AVR lubi innymi urządzeniami jak zewnętrzne pamięci EEPROM, zewnętrzne przetworniki analogowo - cyfrowe, czujniki itp. Może więc nam się przydać przy budowie robota dlatego warto zapoznać się z nim bliżej by móc potem bez większych problemów wykorzystywać go w budowanych konstrukcjach. Urządzenia komunikujące się za pomocą interfejsu SPI dzieli się na dwie podstawowe grupy. Pierwsze to urządzenia Master ( Wyższy ), które inicjują i kontrolują wysyłanie danych oraz urządzenia Slave ( Niewolnik ), które odbierają dane wysyłane przez Master'a ale mogą je do niego także w tym samym czasie wysyłać. Zazwyczaj w prostych rozwiązaniach mamy jeden układ typu Master, który wysyła i odbiera dane od jednego lub kilku układów typu Slave. Najważniejszą część interfejsu SPI stanowi 8-bitowy rejestr przesuwny, który występuje zarówno w urządzeniu skonfigurowanym jako Master jak i Slave oraz sygnał zegarowy generowany przez urządzenie Master. A oto jak przebiega transmisja. Powiedzmy, że Master chce wysłać do układu Slave jakiś bajt nazwijmy go M oraz odebrać od niego również pewien bajt danych nazwijmy go S. Zanim rozpocznie się komunikacja oba urządzenia umieszczają swoje bajty w swoich rejestrach przesuwnych. Zostało to przedstawione poglądowo na rysunku poniżej M0..M7 oznaczają kolejne bity bajtu M podobnie ma się sprawa z bajtem S. Następnie Master generuje 8 pulsów zegara na linii SCK i zawartość rejestru przesuwnego Master'a ( bajt M ) jest wysyłany w takt pulsów zegarowych do Slave oraz w tym samym czasie nadchodzi do Master'a bajt wysyłany przez Slave ( bajt S ). Po pierwszym impulsie zegar sytuacja wygląda tak jak na obrazku niżej. Po następnym impulsie zegarowym mamy taką sytuację. Po 8 pulsach zegara Master ma bajt S a Slave bajt M. To, że transmisja zachodzi w tym samym czasie w obu kierunkach nazywa się w pełni dwukierunkowym transferem danych ( full duplex data transfer ). W mikrokontrolerach AVR cztery piny są używane przy komunikacji SPI : - MISO ( Master in Slave out ) - Tą linią Slave przesyła dane do Master - MOSI ( Master out Slave in ) - Tą drogą docierają dane od Master do Slave - SCK ( Serial Colock ) - To jest linia na, której generowany jest sygnał zegarowy przez urządzenie Master i odbierany przez Slave, zegar jest niezbędny do poprawnego działania SPI gdyż synchronizuje komunikacje to właśnie w takt zegara przesuwane są poszczególne bity w rejestrach przesuwnych. - SS' ( Slave Select ) - W zależności od tego jak skonfigurujemy nasze urządzenie jako Master lub Slave ta linia ma różne znaczenia w obu przypadkach : • SS' dla Slave - Mając w układzie więcej urządzeń Slave niż jedno Master musi mieć możliwość wybrania do którego w danym momencie mają trafić dane a do których nie. Po to właśnie jest linia SS'. Jeżeli SS' jest w stanie wysokim to dany Slave jest niejako nieaktywny i nie odbiera nadchodzących danych natomiast gdy SS' jest w stanie niskim to jest aktywny i nadchodzące dane będą odbierane o ile SPI został poprawnie skonfigurowany. Program Master'a musi kontrolować SS' każdego Slave tak by wysyłać dane tylko do wybranych urządzeń w danym momencie. • SS' dla Master – W tym przypadku mamy jeszcze dwie możliwości w zależności od tego czy pin SS' skonfigurowano jako wejście czy jako wyjście. Jeżeli SS' jest skonfigurowane jako wyjście to czy jest w stanie niskim czy w stanie wysokim nie wpływa na interfejs SPI jest on w obu przypadkach aktywny. Natomiast gdy SS' jest wejściem to musi być trzymane w stanie wysokim by urządzenie pracowało jako Master. Gdy natomiast wystąpi sytuacja, że na SS' będącym wejściem pojawi się stan niski zostanie to zinterpretowane tak jakby inny Master wybrał naszego Master'a jako Slave i rozpoczął z nim komunikacje. Taka sytuacja ( więcej niż jeden Master w układzie ) jest niebyt ciekawa i o ile to nie potrzebne lepiej jej unikać. Jeżeli jest nam to niepotrzebne lepiej konfigurować SS' Master'a jako wyjście wtedy będziemy mieli pewność, że sytuacje tego typu nie wystąpią. W przypadku gdy mamy w układzie tylko jedno urządzenie Slave nie musimy się martwić implementowaniem w programie dla Master'a możliwości przestawiania stanu SS' Slave gdyż i tak nie mamy, żadnego wyboru bo Slave jest tylko jeden. Można wówczas na stałe dołączyć linie SS' Slave do masy wówczas będzie on stale gotów do komunikacji z Master'em. Natomiast pin SS' urządzenia Master można pozostawić niepołączony należy jednak zadbać by był wyjściem gdyż wtedy to w jakim jest stanie ( wysokim czy niskim ) nie ma znaczenia i w obu przypadkach SPI jest aktywne o czym już wyżej wspomniałem. Gdyby był wejściem to nieprzewidziane zmiany stanu mogą skutecznie zablokować komunikacje wystarczy by w jakiś nieprzewidziany sposób stan zmienił się na SS' Master'a na niski i SPI nie będzie działać poprawnie. Pozostałe linie łączymy tak jak na rysunku niżej. Gdy natomiast mamy 2 lub więcej Slave'ów musimy mieć możliwość wybrania jednego konkretnego Slave'a gdy będziemy chcieli wysłać dane tylko do niego. Jak już wiadomo linia SS' w stanie niskim powoduje, że Slave jest aktywny i może komunikować się z Master'em natomiast SS' w stanie wysokim powoduje, że Slave jest nieaktywny i nie odbiera ani nie wysyła, danych. Najprościej więc do wyboru Slave posłużyć się dodatkowymi pinami układu Master podłączonymi do SS' Slave'ów i zmieniając ich stan na wysoki blokować dane Slave'y a na niski uaktywniać je. Pomocny może okazać się poniższy rysunek. Należy tutaj zauważyć, że nazwy MISO, MOSI, SCK, SS' są używane w mikrokontrolerach AVR ale inne urządzenia np. zewnętrzne EEPEROM'y mogą mieć te nazwy inne należy więc sprawdzić w dokumentacji danego urządzenia jak nazywają się odpowiedniki powyższych i z nimi je połączyć. To czy piny używane podczas komunikacji SPI są wejściami czy wyjściami zależy od tego czy urządzenie skonfigurowano jako Master czy jako Slave. Są tutaj dwie możliwości albo mamy narzucone, ustawienie danego pinu jako wejście albo kierunek pinu musi być ustalony przez programistę zgodnie z tym jaką funkcje pełni. Pomocna może być poniższa tabela. Przed przystąpieniem do analizy kodu przykładowych programów należy jeszcze podać minimum informacji na temat rejestrów sterujących SPI tak aby kody były dla wszystkich zrozumiałe. Do sterowania interfejsem SPI w mikrokontrolerach AVR ATmega8 służą 3 rejestry SPCR, SPSR oraz SPDR. Nie będę na razie podawał znaczenia wszystkich bitów danych rejestrów podam tylko te niezbędne do zrozumienia kodów reszta zostanie uzupełniona później. Na pierwszy ogień weźmy rejestr SPCR ( SPI Control Register ) będą nas tu na razie interesować następujące bity : - SPE ( SPI Enable ) - Bit ten musi być ustawiony kiedy chcemy używać interfejsu SPI gdyż ustawienie tego bitu powoduje po prostu włączenie interfejsu SPI. - SPIE ( SPI Interrupt Enable ) – Bit ten ustawiamy kiedy chcemy aby przerywania pochodzące od interfejsu SPI były włączone jeżeli nie chcemy korzystać z przerywań bit powinien mieć wartość 0. Należy pamiętać, że aby korzystać z przerywań należy w rejestrze SREG ustawić wcześniej bit I co czyni w asemblerze instrukcja sei a w C funkcja sei(). - MSTR ( Master / Slave Select ) - Nadanie bitowi wartości 1 powoduje, że urządzenie pracuje jako Master natomiast nadanie mu wartości 0 powoduje pracą urządzenia jako Slave. - SPR1 i SPR0 – Bity te służą do konfiguracji częstotliwości sygnału zegara SPI generowanego przez Master'a na linii SCK. Jeżeli urządzenie skonfigurowano jako Master to można zmieniając wartości tych bitów ustawiać dzielnik przez, który zostanie podzielona częstotliwość oscylatora mikrokontrolera i tak otrzymaną częstotliwość będzie miał sygnał zegarowy generowany przez Master. Z racji, że dane są przesyłane w takt zegara zmieniając wartości bitów a co za tym idzie częstotliwość zegara SPI można zmieniać szybkość przesyłanych danych. Należy zauważyć, że jeżeli urządzenie skonfigurowano jako Slave to ustawienie tych bitów nie ma znaczenia gdyż Slave tylko odbiera sygnał, który generuje Master. Nie można jednak zapomnieć o ograniczeniach narzucanych przez sam sprzęt, które powodują, że częstotliwość zegara SPI nie może być większa niż fosc / 4 gdyż wtedy dane nie będą poprawnie odbierane. Poniższa tabelka przedstawia możliwości ustawienia dzielnika za pomocą bitów SPR1 i SPR0. Pora na rejestr SPSR ( SPI Status Register ) na razie będzie nas interesował tylko bit SPIF tego rejestru. - SPIF ( SPI Interrupt Flag ) - Jest to bit, który można tylko odczytywać nie można więc go ustawiać lub kasować programowo gdyż to sprzęt nim steruje. Jest on ustawiany przez sprzęt kiedy transfer SPI dobiegnie końca . Jest on kasowany przez sprzęt kiedy zostanie zgłoszone przerywanie od SPI ( SPI_STC ) i zaczyna się procedura jego obsługi lub jest kasowany wtedy gdy nastąpi odczytanie bitu SPIF i zawartości rejestru SPDR. Na koniec rejestr SPDR - Do tego rejestru zapisujemy dane do wysłania przez Master lub Slave oraz z tego rejestru odczytujemy nadchodzące dane po stwierdzeniu końca komunikacji, do czego może posłużyć wyżej opisana flaga SPIF lub przerywanie SPI_STC. Po poprawnym zainicjowaniuinterfejsu SPI wystarczy tylko wpisać do tego rejestru wartość do wysłania aby transmisja została rozpoczęta. Teraz przejdziemy do części praktycznej zostaną przedstawione dwa proste przykłady użycia interfejsu SPI. Pierwszy z nich prezentuje użycie interfejsu SPI w bardzo prosty sposób. Drugi na przykładzie urządzenia Slave pokazuje wykorzystanie przerywania SPI_STC ( Spi Transfer Complete ) do wykrycia końca transmisji danych. Żeby móc przetestować pokazane przykłady wystarczy złożyć następujący prosty układ : Gdybym się pomylił lub o czymś zapomniał przy rysowaniu schematu to napisze jeszcze słowami, że w sumie nie chodzi o nic więcej jak tylko połączenie ze sobą pinów MISO, MOSI, SCK obu układów pin SS' Slave łączymy z masą a do jego PortuD dołączamy diody ledukłady oczywiście podłączamy do napięcia 5V i dodajemy kondensatory odsprzęgające o wartościach C4 i C3 100nF ceramiczne oraz C5 i C6 10uF elektrolity natomiast reset łączymy z vcc przez rezystor 10k i z minusem przez kondensator 100nF. Układ jest dość prosty a dane, które będzie otrzymywał Slave od Master'a są wyświetlane na 8 diodach połączonych do pinów portu D. Możemy dzięki temu stwierdzić czy interfejs działa poprawnie i czy wszystko zostało dobrze złożone. Do przykładów wykorzystano 2 AVR'y Atmega8 i na takich właśnie mikrokontrolerach kody będą działać poprawnie przy stosowaniu innych należy zgodnie z dokumentacją zmienić część kodu. Układ testowy został złożony na płytce stykowej ale oczywiście można go także złożyć na płytce uniwersalnej lub na płytce drukowanej. Programy zostały napisane w 2 językach programowania w AVR Asemblerze i AVR – GCC. Pierwszy program ( animacja ) działa tak, że na diodach led wyświetlane są kolejne bajty wysyłane przez Master te bajty to nic innego jak coraz większe ( o jeden ) liczby od 0 do 255 z racji, że master po wysłaniu bajtu odczekuje ok. 1 sekundy efektem jest prosta animacja. Najpierw kody dla urządzenia Master. Wersja ASM .include "m8def.inc" .cseg .org 0x000 rjmp Start Start: ldi r16, low( RAMEND ) out SPL, r16 ldi r16, high( RAMEND ) out SPH, r16 Inicjajcja_spi: ldi r16, ( 1 << PB3 )|( 1 << PB5 ) | ( 1 << PB2 ) //MOSI, SCK, SS' jako wyjścia out DDRB, r16 ldi r16, ( 1<<SPE )|( 1<<MSTR )|( 1<<SPR0 ) | ( 1 << SPR1 ) //Włączamy SPI, układ Master out SPCR, r16 //Najmniejsza częstotliwość SCK fosc / 128 ldi r19, 0 main: //Pętla nieskończona out SPDR, r19 //Wysyłamy zawartość r19 inc r19 //Zwiększamy wartość w r19 o 1 Czekaj_na_wyslanie: //Oczekujemy na zakończenie transmisji ( do ustawienia SPIF ) sbis SPSR, SPIF //Przez sprzęt rjmp Czekaj_na_wyslanie ldi r16, 250 //Czekamy ok. 1 sek rcall Czekaj ldi r16, 250 rcall Czekaj ldi r16, 250 rcall Czekaj ldi r16, 250 rcall Czekaj rjmp main Czekaj: //Procedura opóźniająca o 1 * r16 [ ms ] P2: ldi r17, 10 P1: ldi r18, 25 P0: nop dec r18 brne P0 dec r17 brne P1 dec r16 brne P2 ret Wersja C #define F_CPU 1000000UL #include<avr/io.h> #include<util/delay.h> void Inicjacja_spi() { DDRB = ( 1 << PB5 ) | ( 1 << PB3 ) | ( 1 << PB2 ); //MOSI, SCK, SS' jako wyjścia SPCR = ( 1 << SPE ) | ( 1 << MSTR ) | ( 1 << SPR1 ) | ( 1 << SPR0 ); //Włączamy SPI, } //układ Master, najmniejsza częstotliwość SCK fosc / 128 void Wyslij_spi(char bajt) { SPDR = bajt; //Wysyłamy zawartość zmiennej bajt while( ! bit_is_set( SPSR, SPIF ) ); //Oczekujemy na zakończenie transmisji ( do ustawienia SPIF ) przez sprzęt } int main() { char bajt = 0; Inicjacja_spi(); while(1) //Pętla nieskończona { Wyslij_spi(bajt); _delay_ms(250); //Czekamy ok. 1 sek _delay_ms(250); _delay_ms(250); _delay_ms(250); bajt++; //Zwiększamy wartość w bajt o 1 } return 0; } Teraz kod dla Slave Wersja ASM .include "m8def.inc" .cseg .org 0x00 Inicjajcja_spi: ldi r16, ( 1 << PB4 ) //MISO jako wyjście out DDRB, r16 ldi r16, ( 1 << SPE ) //Włączamy SPI out SPCR, r16 ldi r17, 0xff //Cały PortD jako wyjście out DDRD, r17 ldi r17, 0x00 //W stanie niskim out PORTD, r17 main: sbis SPSR,SPIF //Czekamy na koniec transmisji danych ( do ustawienie flagi SPIF ) rjmp main in r16, SPDR //Wpisujemy to co przyszło od Master do r16 out PORTD, r16 //Wysyłamy to na PortD ( diody led ) rjmp main //I tak bez końca Wersja C #include<avr/io.h> void Inicjacja_spi() { DDRB = ( 1 << PB4 ); //MISO jako wyjście SPCR = ( 1 << SPE ); //Włączamy SPI } char Odbieraj_spi() { //Czekamy na koniec transmisji danych while ( ! bit_is_set( SPSR, SPIF ) ); // ( aż do ustawienie flagi SPIF ) return SPDR; //Zwracamy to co dostaliśmy do SPDR } //Czyli to co wysłał Master int main() { DDRD = 255; PORTD = 0; Inicjacja_spi(); while(1) { char bajt = Odbieraj_spi(); PORTD = bajt; //Wysyłamy to co dostaliśmy od Master'a na } //PortD ( diody led ) return 0; } Programy nie są trudne ale warto przenieść je na język ludzki na listę czynności które wykonują tak by widzieć co po kolei należy zrobić by wysyłać dane przez SPI. Master 1. Najpierw inicjujemy SPI ustawiając MOSI ( PB3 ) , SCK ( PB5 ), SS' ( PB2 ) jako wyjścia co jest zrozumiałe gdyż sygnał zegarowy generuje Master a Slave go odbiera więc jeśli u Slave jest on ustawiany jako wejście zgodnie z wcześniejszą tabelką to u Master pasuje by był wyjściem podobnie ma się rzecz z MOSI a co do SS' to już było pisane, że ustawienie jako wyjście pozwala nam unikać przykrych sytuacji. Ta część wymaga zmian przy innych mikrokontrolerach bo mogą one mieć MISO, MOSI, SCK, i SS' na innych pinach niż Atmega8. 2. W dalszej części inicjacja ustawiamy odpowiednie bity w rejestrze SPCR czyli SPE ( włączamy SPI ) MSTR ( układ to Master ) SPR0 i SPR1 ustawiają najmniejszą częstotliwość SPI fosc / 128 co pozwala zminimalizować ryzyko zakłóceń do minimum i być może oszczędzić niektórym niepotrzebnych nerwów. 3. Następnie program wysyła bajt do Master rozpoczęcie wysyłania jest równoznaczne z wpisaniem bajtu do rejestru SPDR. 4. Następnie odczekujemy na koniec transmisji danych chodź nie jest to w 100 procentach potrzebne gdyż program i tak czeka potem 1 sekundę ale co nam szkodzi robimy to poprzez oczekiwanie na zmianę stanu SPIF na 1 co zrobi sprzęt gdy transmisja bajtu dobiegnie końca gdy to się stanie możemy już wysyłać kolejny bajt. Slave 1. Najpierw inicjujemy SPI ustawiając MISO ( PB3 ) jako wyjście. 2. W dalszej części inicjacji włączamy SPI ustawiając bit SPE 3. Wpadamy w pętle w której oczekujemy na koniec transmisji ( odebranie danych od master ) o czym da znać bit SPIF mający wartość jeden. 4. Jeśli SPIF ma wartość jeden oznacza to, że dane dotarły i możemy je odczytać gdyż są teraz w rejestrze SPDR więc i to robimy. Teraz druga wersja programu robi w sumie to samo co pierwsza tyle, że urządzenie Slave wykorzystuje przerywanie SPI_STC do wykrycia końca transmisji danych. Kody dla Master są w tym przypadku takie same zmienia się tylko kod dla Slave. Oto one : Wersja ASM .include "m8def.inc" .cseg .org 0x000 rjmp Start .org 0x00A rjmp SPI_Int SPI_Int: //Ten kod zostanie wykonany po zgłoszeniu przerywania SPI_STC in r16, SPDR //Pobieramy wartość wysłaną przez Master out PORTD, r16 //Wysyłamy na PortD ( wyświetlamy ją na diodach led ) reti Start: ldi r16, low( RAMEND ) out SPL, r16 ldi r16, high( RAMEND ) out SPH, r16 sei //Włączamy przerywania ldi r16, ( 1 << PB3 ) //Inicjacja Slave jak poprzednio out DDRB, r16 ldi r16, ( 1 << SPIE ) | ( 1 << SPE ) //Włączamy przerywania i interfejs SPI out SPCR, r16 ldi r16, 0xff out DDRD, r16 ldi r16, 0x00 out PORTD, r16 main: rjmp main Wersja C #include<avr/io.h> #include<avr/interrupt.h> ISR(SPI_STC_vect) //Kod wykonywany po zgłoszeniu przerywania SPI_STC { char bajt = SPDR; //Pobieramy wartość wysłaną przez Master PORTD = bajt; //Wysyłamy na PortD ( wyświetlamy ją na diodach led ) } void Inicjacja_spi() { DDRB = ( 1 << PB4 ); //Jak poprzednio SPCR = ( 1 << SPIE ) | ( 1 << SPE ); //Włączamy przerywania i interfejs SPI } int main() { DDRD = 255; PORTD = 0; Inicjacja_spi(); sei(); //Włączamy przerywania for (;;); return 0; } W sumie nie ma tu wielkich różnic więc nie ma co się rozpisywać bo przecież tłumaczenie jak obsługiwać przerywania nie należy do tego tematu i wszyscy powinni już to wiedzieć chyba, że są tacy co zaczynają stawiać dom od dachu. Wiedzieć należy jednak to, że po zgłoszeniu przerywania od SPI program skacze do adresu 0x00A, natomiast w C powinniśmy do funkcji obsługującej przerywania podać nazwę SPI_STC_vect . W sumie jedyną nowością jest ustawienie w rejestrze SPCR bitu SPIE, który włącza przerywania od SPI. Na razie tyle ciąg dalszy nastąpi wkrótce.
  11. 15 punktów
    Witam. Po dłuższym czasie mojej nieobecności na forum postanawiam przedstawić mojego (z kilku na które przyjdzie czas by je zaprezentować ) robota. Zwie się on FRodo i jest robotem o niekonwencjonalnej budowie. Strona techniczna FRodo posiada przekładnię Tamiya i gąsienice pololu. Mimo tak słabego napędu robot mało co nie rwie gruntu dzięki ustawieniu go na najmniejsze przełożenie i dołożenie mu mocniejszych silników. Podwozie to płyta główna na której znalazły się tradycyjne mostki L293Dx2, sharp 340K oraz atmega32. Brakuje tam czujnika odbiciowego ale to sprawia że robot niczego się nie boi. Nad podwoziem znajduje się owa przekładnia ,bateria(500mAh) ,trochę ołowiu i coś czego jeszcze nie było w żadnej maszynie czyli podnośnik. Znajduje się tam także 3-kierunkowy przełącznik z cd-roma do wcześniejszego wpisania do pamięci gdzie znajduje się przeciwnik. Podnośnik i wola powstania Siedząc raz na lekcji wpadłem na pomysł jak przeważyć na przeciwnikiem przy użyciu serwa i kawałka laminatu. Wykonałem na szybko płytę główną. Ze złomu znalezionego z rozebranych starych robotów zmontowałem nowe podwozie o wysokości 3,5cm i zainstalowałem serwo po czym doczepiłem do niego kawałek laminatu.Tak oto powstał FRodo wtedy jeszcze figurujący pod nazwą player1. Po kłopotach z silnikami w przekładni oraz znacznej modyfikacji tej maszyny nazwałem go FRodo. Tryb koło włącznika funkcjonuje jako łożysko do podnośnika aby serwo zbytnio się nie męczyło. Oprogramowanie Soft został napisany w bascomie zajmuje on 25% pamięci. Kod ma ponad 550 linijek i zakłada on wliczanie kontu przyłożenia oraz tworzy tablicę obecności przeciwnika właśnie z takiego powodu mam tylko jeden czujnik ponieważ przy większej ilości musiał bym strwożyć nowe tablice danych a gromadzenie większej ilości danych zabiera takty procesora i wymaga bardziej rozbudowanego kodu. Skrypt ten zastosowałem w obydwu moich nowych minisumo i obydwa nie powalają sposobem wykonania ale za to dostały się do półfinałów. Pod podnośnikiem znajduje się deska rozdzielcza na której znajdują się złącza jednym z nich jest rs232. Podłączam do niego moją elektroniczną ściągę i mogę zmieniać wypełnienie PWM oraz wprowadzać wartości rożnych zmiennych takich jak współrzędne na dohyo. Wnioski z budowy robota Ogólnie jestem zadowolony z maszyny. Fakt że wydałem na niego tylko 60zł jest tym śmieszniejszy że odbywając 3 walki z robotem Enova wygrałem 2 więc śmiało stwierdzam że ta maszyna jest czarnym koniem zawodów w Rzeszowie. W przyszłości dołożę więcej czujników i wymienię podnośnik na metalowy. Poniżej dodaję zdjęcia.
  12. 14 punktów
    Witam serdecznie, tematyką robót bezwykopowych zajmuję się już 3 lata. Chciałem przedstawić jeden z projektów - pojazd do inspekcji kanalizacji. Jeśli nazwałbym go robotem pewnie byłoby to przesadą. System składa się z panelu operatorskiego (z reguły duży samochód z agregatem, monitorami - do wyświetlania tego co widzi kamera umieszczona na pojeździe, drukarką, nagrywarką, ogrzewaniem etc.) oraz małego pojazdu poruszającego się w rurach. Połączenie realizuje się przewodowo (bardzo rzadko bezprzewodowo), co czyni "prawie robota" pojazdem sterowanym przez teleoperatora. Czy inspekcja rurociągów często się zdarza? Całkiem sporo się tego wykonuje - podczas odbioru rurociągu oraz gdy się stanie coś złego. Pojazd Sterownik pojazdu: układ oparty o uC ATmega32 Komunikacja: RS-485, sterowanie prędkością pojazdu, kierunkiem, intensywnością oświetlenia Napęd: 4 silniki Sanyo Denki 103G770 Sterowniki silników: 4 układy oparte o L297 i L298 Koła: wytoczone z aluminium PA11 na tokarce, opony z LEGO System wizyjny: dowolna kamera pozwalająca osiągnąć wyraźny obraz, nie ma sparametryzowanych wymagań (użyłem płytkowej kamery SHARP) Oświetlenie: w kanałach jest ciemno; równomierne oświetlenie uzyskane dzięki pierścieniowi LED Obudowa: tutaj są ścisłe wymagania na kształt, materiał, szczelność; w moim przypadku w pełni zaprojektowana, nie wykonana ze względu na koszta Zasilanie: 24V DC przekazywane przewodami Panel operatorski - interfejs Obudowa: walizka z demobilu Monitor: LG 15.1" Procesor: dwurdzeniowy Intel Atom 1.6 GHz Karta graficzna, dźwiękowa etc. : zintegrowana na płycie głównej Łapanie obrazu: karta DVR Interfejs użytkownika: w pełni wodoodporna klawiatura ze zintegrowaną myszą Dysk: SSD 32 GB Zasilacz ATX (fajna zabawka!): napięcie wejściowe 6-30 V, moc 300 W Panel operatoski - zasilanie w ogóle 350 Watt'ów tylko i wyłącznie z pasywnym chłodzeniem, dzięki czemu cała walizka może być wodoodporna
  13. 13 punktów
    Dane techniczne: Robot czteronożny o konstrukcji aluminiowej (własnego projektu) – waga 670 gramów. Wymiary nogi robota w stanie rozłożonym od osi serwa do końca nogi to 19 cm. Body o wymiarach 8 x 8 cm. A na pokładzie mamy: - Kontroler robota to Baby Orangutan B-328 Robot Controller – programowany w oparciu o dobrze znane nam środowisko Arduino wersja 0021. - 2 x sterowniki serw Pololu Micro Serial Servo Controller do sterowania serwami, - 12 mini serwomechanizmów Tower Pro MG-16R – mocne serwa metalowe o momencie ok. 2,7 kg / cm, - 4 Sharp’y GP2Y0A21YK0F – jako czujniki odległości. Zasięg prezentowany przez producenta to 10-80cm. W rzeczywistości spokojnie można sobie analizować otoczenie powyżej 1 m. - Czujnik przyspieszeń MMA7341L 3-Axis Accelerometer ±3/11g z własnym regulatorem napięcia, - 4 czujniki dotyku w oparciu o włączniki, - MOBOT-RCR-V2 -Moduł radiowy 868MHz – do połączenia bezprzewodowego z rękawicą. - Robot jest zasilany z Pakietu LiPol 3E Model 1300mAh 11,1V 15C, - Regulator Pololu Step-Down Voltage Regulator D15V35F5S3 do zasilania serw, - Stabilizator AVT MOD13 do zasilania elementów nie posiadających własnego regulatora. Sterowanie robotem poprzez rękawicę ( w fazie testów) zawierającą na swoim pokładzie: - Kontroler Orangutan SV-328 z wyświetlaczem LCD - MOBOT-RCR-V2 -Moduł radiowy 868MHz – do połączenia bezprzewodowego z robotem. - Czujnik przyspieszeń MMA7341L 3-Axis Accelerometer ±3/11g z własnym regulatorem napięcia za pomocą, którego są prowadzone odczyty. Robot obecnie przeszedł pozytywnie fazę testów poszczególnych elementów po złożeniu i jest oprogramowywany. Przewidziano 2 podstawowe typy pracy: 1. Sterowanie z rękawicy – tj. odczyty z czujnika przyspieszeń przekazywane są do robota za pomocą modułu radiowego gdzie następuje zaprogramowana reakcja. 2. Praca autonomiczna – robot dokonując odczytów ze swoich czujników reaguje na zmiany otoczenia podczas poruszania się.
  14. 12 punktów
    Zgodnie z obietnicą uzupełniłem ilość informacji o "Bajtlu" Witam Przedstawiam mojego trzeciego robota, jest nim linefollower "Bajtel". Jest on następcą robota "Urwis", o którym można poczytać tutaj. Robot był budowany z myślą o zawodach T-bot w Wałbrzychu, wystartował również na zawodach Robotic Tournament w Rybniku. Napęd: 2x silnik DG2425-016 (z mobota), koła własnej roboty, trzecie koło - "kulkowe". Zasilanie: 6x akumulatorki AA 1.2V Elektronika: ATmega8, L293D, 5x CNY70, dwie diody LED, dwa przyciski, dodatkowy rezonator 12Mhz (który nie działa). Obudowa: laminat miedziowany jednostronnie, polutowany i pomalowany czerwoną farbą, części mocowane za pomocą śrubek M3, nakrętek i tulejek dystansowych. Program: pisany w BASCOMIE, wykorzystuje przetwornik A/C i timer jako PWM. Zmiany wersji II: - koła z plastiku zamiast aluminium, - zmieniony układ czujników - oczywiście zmieniony program T-bot 2010: 7 miejsce 1-szy przejazd: 19,99 2-gi przejazd: nieukończony (podjęte świadome ryzyko) 3-ci przejazd: 20,05 Myślę, że te wyniki da się jeszcze poprawić, trzeba tylko usunąć jedną wadę. Filmik z 3 przejazdu: Robotic Tournament 2010: 2 miejsce Trasa pierwsza: 0,23,18 ; 0,23,07 Trasa druga: 0,27,16 ; 0,26,37 Finał: jeszcze nie znam dokładnie, trochę ponad 26s. Filmik z przejazdów: Podsumowanie: Jeżeli ktoś przejrzał temat z "Urwisem", to pewnie zauważył, że "Bajtel" to po prostu jego wersja rozwojowa, konstrukcja niemalże ta sama, ale dużo większa i cięższa, za to szybsza. W zasadzie jako takie prace nad "Bajtlem" dobiegły końca, wyciągnąłem nowe wnioski i przymierzam się powoli do budowy następnego robota. Jedyne poprawki to mogą być jakieś retusze w programie alb zmiana rozstawienia czujników. Nie znaczy to, że "Bajtel" nie będzie się już pojawiał na zawodach, bo jego umiejętność pokonywania trudnych i krętych tras rekompensuje w całości nieradzenie sobie na prostych odcinkach i łagodnych łukach. Sądzę, że postęp od "Urwisa" jest bardzo duży, dlatego traktuję tego robota jako udanego. Dziękuję mojemu koledze z klasy i zespoły Stachowi za pomoc przy testowaniu robota w szkole i podczas zawodów oraz za udostępnienie swojego laptopa. Aby "Bajtel" powstał, musiał swoje silniki i inne części oddać "Urwis" . Uczcij go Czytelniku minutą ciszy, albo postaw piwo.
  15. 11 punktów
    ZDALNIE STEROWANY SAMOBIEŻNY MANIPULATOR OPERACYJNY DO ZADAŃ SPECJALNYCH Chciałbym zaprezentować mój kolejny duży projekt, będący zarazem moją pracą inżynierską. Praca jest dość złożona, wymagała dużego nakładu pracy, wykorzystania narzędzi do projektowania i obejmowała głównie trzy nurty - mechanikę, elektronikę i informatykę. Zostałem poproszony o przedstawienie go również na forum PRA które wyjątkowo pasuje do tego projektu. WSTĘP W grudniu ubiegłego roku skończyłem i opublikowałem mój poprzedni projekt zaawansowanego systemu oświetlenia, dostępny na forum elektroda.pl. Pomimo tego, że był on pracochłonny a termin obrony się zbliżał postanowiłem jednak to co zacząłem najpierw dokończyć zanim zabiorę się za prace dyplomową. Z tego wynika, że projektowanie i budowa manipulatora trwała około 4 miesiące od stycznia do kwietnia, czas gonił jednak dobre rozplanowanie pracy to gwarancja sukcesu. Długo zastanawiałem się w jakiej formie umieścić post na forum, szczerze spisałem się już dość w samej pracy i doszedłem do wniosku że nie będzie długiego opisu i wielu zdjęć jak zwykle, było by wręcz za dużo materiału. Przedstawię tylko garstkę najważniejszych informacji w tym to co może zainteresować forumowiczów, potem natomiast zachęcam do pobrania elektronicznej wersji pracy, gdzie bardzo szczegółowo na 123 stronach opisano proces projektowania, wszystkie elementy składowe oraz sam etap tworzenia manipulatora i wykonane testy. Zamieszczam też zdjęcia w większej rozdzielczości z wszystkich etapów powstawania konstrukcji a także do wglądu program sterujący w wersji v1.1, w nim znajduje się opis funkcji i sposobu sterowania, dla dociekliwych. Przygotowałem też dwa filmiki, jeden pokazujący działającą aplikacje i obraz z kamery a drugi pokazujący manipulator. Chciałbym z góry zaznaczyć, że nie udostępniam projektów elementów konstrukcji manipulatora, plików schematów i płytek obwodów elektronicznych oraz źródeł programów. W pracy zamieszczono za to dokładne rysunki manipulatora, są też rysunki schematów i płytek oraz fragmenty listingów z rozwojowych i testowych wersji programów. Nie musze dodawać chyba że praca inżynierska jak każda inna chroniona jest prawami autorskimi. GŁÓWNE ZAŁOŻENIA Mniej więcej rok temu gdy należało zadeklarować wybrany temat pracy, postanowiłem zbudować coś niebanalnego. Do głowy przyszło mi coś podobnego do używanych przez służby policyjne/saperskie robotów do przenoszenia niebezpiecznych przedmiotów. Przedstawiłem wówczas promotorowi wstępny temat pracy i jej założenia wraz z krótkim opisem: “Tematem pracy dyplomowej ma być manipulator o kilku stopniach swobody oparty o konstrukcje aluminiową i serwomechanizmy modelarskie, co pozwoli na chwytanie i przenoszenie przedmiotów, zbudowany na podwoziu gąsienicowym z napędem elektrycznym dzięki czemu umożliwi to poruszanie się w różnym terenie, z własnym zasilaniem akumulatorem żelowym 6V, sterowany przy wykorzystaniu szeregowego portu komunikacyjnego komputera PC z zainstalowanym programem pozwalającym kontrolować pracę serwomechanizmów za pomocą danych wprowadzanych z klawiatury lub dołączonego sterownika(joystick/joypad). Transmisja sygnału będzie odbywać się za pomocą toru radiowego przy wykorzystaniu modułów pracujących na częstotliwości 433MHz lub innej, W opcji urządzenie może być wyposażone w kamerę i oświetlacz podczerwieni, przy czym obraz będzie przesyłany również drogą radiową do odbiornika, którym będzie mogła być stacja robocza typu laptop z wejściem AV.” Konstrukcja taka chodziła mi po głowie od pewnego czasu przy czym warto zaznaczyć, że moim jedynym doświadczeniem z robotyką był tylko kit AVT821, który okazał się mechanicznie wysoce nieprzemyślaną przez twórcę konstrukcją, ponadto doszedł problem z jego sterowaniem w systemie XP. Pomogła zmiana sterownika na sterownik serwomechanizmów z zestawu NE041, choć jego program jest nie za bardzo funkcjonalny, kilka dni temu z nudów napisałem własny. Gdyby ktoś kto używa go w swojej konstrukcji zestawu NE041 był zainteresowany zmienionym programem mogę udostępnić go wraz ze źródłami lub zmodyfikować wg potrzeb. KONSTRUKCJA MECHANICZNA Projekt elementów składowych, powstawał w środowisku Autocad Inventor 9. Zaczęło się od podwozia które dostosowałem do zakupionych gąsienic z modelu czołgu i kół współpracujących z gąsienicami. Później powstały pozostałe elementy, stopniowo płyta górna, obrotnica na której powoli zaczęło powstawać ramię. Na tym etapie przydała się bardzo suwmiarka elektroniczna, powstały szczegółowe rysunki serwomechanizmów, które planowałem użyć następnie jak klocki lego łączono w programie za pomocą kolejnych elementów ramienia. Program umożliwia symulacje ruchów i wykrywanie kolizji co bardzo się przydało i pozwoliło zaobserwować prace poszczególnych stopni swobody już na monitorze komputera, na przykład można nałożyć wiązania ruchowe i zaobserwować pracę chwytaka i zębatych elementów go napędzających. Do posiadanej wersji Inventora nie miałem bibliotek, wszelkie elementy nawet śrubki, podkładki czy nakrętki M3 rysowałem sam. Praca w Inventorze jest bardzo intuicyjna, wciągająca i przyjemna(o ile się go lubi oczywiście) i osoby mające z nim kontakt pewnie stwierdzą podobnie. Detale można dopracować do perfekcji jak chociażby stworzony model serwa S03T któremu brakuje jedynie przewodu, poza tym jest dopracowane w najmniejszych szczegółach, powstał nawet dedykowany mu orczyk który scala wał serwa i płytki ramion ze sobą. Potem wszystko było dopracowywane pod kątem ergonomii, tak by najlepiej współpracowało z resztą. Z wielu możliwości wykonania samego chwytaka zdecydowałem się na właśnie taką wersje jaka jest obecnie. Jako budulca zamiast aluminium zdecydowałem się jednak na użycie laminatu, głównie ze względu na to iż przy stawianych mu w projekcie wymaganiach jego właściwości nie są gorsze od aluminium, za to łatwiejsza jest obróbka jak i łączenie. Zdobycie laminatu okazało się też łatwiejsze a i obróbka jest tańsza. Pierwotnie bowiem zaprojektowane elementy miały być wyeksportowane do formatu DXF i wycięte w jednej z firm zajmującej się produkcją obwodów elektronicznych za pomocą frezarki CNC. Jednak gdy po wycenie dowiedziałem się że kosztowało by to 150zł(materiał+wykonanie) plus koszty przygotowania dokumentacji 500zł(klikanie w klawisze), zamówiłem w innej firmie jedynie wstępnie docięty laminat i wszystkie pojedyncze elementy, zaokrąglenia czy otwory wykonałem ręcznie przy użyciu podróbki dremelka, jak widać nie takiej złej jakości, skoro w poprzednim projekcie wywierciłem nim przy użyciu jednego zresztą wiertła widiowego 0,7mm ponad 1500 otworków pod rząd, a teraz za pomocą kilku tarczek korundowych udało się wyciąć wszystkie części składowe. Cięcie pozostawiło w moim pokoju ślady które usuwałem jeszcze długo po nim, mianowicie cały ten wszechobecny pył. Pomimo okularów ochronnych miałem go nawet na rzęsach. Potem za pomocą małego frezu pozostało wyrównać wszystkie cięte krawędzie. Jedynie większe otwory wykonane były dużą wiertarką. Następnie elementy przymierzono i po stwierdzeniu że wszystko pasuje, płytki przeszlifowałem aby usunąć zadziory i nierówności, umyłem i odtłuściłem. Po wstępnym montażu podwozia, gdzie przewidziano połączenia lutowane całość okazała się bardzo solidna i sztywna. Po tym laminat został polakierowany, czarny mat wyszedł rewelacyjnie, można było pomyśleć że to jakieś gotowe odlewy z fabryki, a miejsca lutowania nabrały wyglądu spawów wykonanych automatem. Potem po wykonaniu szablonu malarskiego powstał ostrzegawczy żółto-czarny wzór. Wszystko malowane było lakierami w sprayu. Polecam czarny mat. Szczegółowy opis w pracy, kilka danych technicznych: Waga – około 5kg (zależy od stanu naładowania akumulatora ) Długość całkowita – 37,5cm Szerokość – 23cm Szerokość gąsienicy – 45mm Prześwit – 23mm Wysokość ramienia w najwyższym punkcie – około 40cm Max. średnica chwytanych przedmiotów – 65mm Max. waga przenoszonych przedmiotów – około 0,5kg SERWOMECHANIZMY Elementy nadające ruch to w sumie aż 10 serwomechanizmów różnych typów i producentów. Szczegółowy ich opis znajduje się w pracy, a na uwagę zasługuje tu przeróbka serw napędowych tak by usunąć blokadę obrotu. Do wszelkich modyfikacji najlepiej nadają się serwomechanizmy GWS S03X, zarówno usunięcie blokady obrotu oraz wykonanie osi po drugiej stronie(tak by możliwe było zamocowanie ramienia z drugiej strony wału napędowego) są bardzo proste i możliwe do wykonania, zupełnie jakby producent przewidział taką potrzebę. Problem pojawił się gdy we wszystkich sklepach w Polsce znalazłem w sumie tylko trzy wersje S03T 2BBMG czyli najlepsze z serii standard z metalowymi przekładniami i łożyskami tocznymi i momentem prawie 9kg/cm, podczas gdy potrzebowałem pięciu(w tym dwa do napędu gąsienic). Te dwa więc musiałem zastąpić innymi o jak najlepszych parametrach(szybkość i moment) i możliwości ich modyfikacji. Najlepszym z dostępnych na tamtą chwile rozwiązań okazał się model Hitec 325HB o wzmocnionych przekładniach i dwóch łożyskach a przede wszystkim można je łatwo zmodyfikować. A apropo samej modyfikacji, gdziekolwiek bym nie słyszał o czymś takim, wszędzie po usunięciu blokady usuwa się potem elektronikę i zasila silnik bezpośrednio. Owszem dobre jak ktoś chce i może sterować takim silnikiem potem za pomocą PWM czy mostka H. Ja natomiast chociażby ze względu na ograniczoną ilość pinów a także na uproszczenie sterowania zdecydowałem się pozostawić elektronikę i sterować serwem zupełnie tak jak wcześniej. Usunięta została blokada i sprzężenie wału z potencjometrem, który ustawiłem w pozycji środkowej i zablokowałem. Impulsy równy 1,5ms powoduje zatrzymanie serwa, większe od neutralnego 1,5ms powodują płynne zwiększanie obrotów w jedną stronę i vice versa. Proste prawda?? ELEKTRONIKA Elektronika manipulatora składa się z części nadawczej dołączonej do komputera sterującego oraz odbiorczej umieszczonej w manipulatorze. Nadajnik używa portu komunikacyjnego RS-232C z którego dane po zmianie poziomów logicznych przepuszczane są przez mikrokontroler i wpuszczane na moduł nadawczy RTFQ2 firmy Telecontrolli. Modułów radiowych oczywiście nie było w bibliotekach Eagla, w którym oczywiście powstała całość, więc narysowałem je sam. Na dobrą sprawę jak może niektórzy zauważą mikrokontroler w nadajniku można by pominąć, zwłaszcza że ATmega8 trochę marnuje się w tym miejscu, ale zdecydowałem się rozszerzyć funkcjonalność i ułatwić przygotowanie transmisji, zwłaszcza zostawiając sobie możliwość wprowadzenia modyfikacji w przyszłości. Nadajnik jest w zasadzie nazywany urządzeniem nadawczo-odbiorczym, gdyż zawiera w górnej części wbudowany odbiornik kamery bezprzewodowej dołączany do portu USB. Aby stacja sterująca była uniezależniona od zasilania zewnętrznego z portu USB pobierane jest również zasilanie dla nadajnika. W przypadku użycia laptopa ze sprawnym akumulatorem nie trzeba się martwić o dostęp do gniazdka i sterować manipulatorem możemy wszędzie. Ostatecznie również udało się rozwiązać problem transmisji danych szeregowych za pomocą dostępnych gotowych modułów radiowych. Często czytałem na elektrodzie o powodzeniach lub porażkach(częściej tym drugim) przy próbach przesłania czegoś przez RS-232C bezprzewodowo. Jak wiadomo choć wiele osób tego nie doczytuje nadajniki i odbiorniki radiowe wymagają zakodowanego sygnału do przesłania, najlepiej typu Manchester. Okazało się że para moduł radiowy plus układ MC14502X(koder/dekoder Manchester) przynajmniej w moim przypadku nie nadawała się do transmisji danych szeregowych. Owszem wszystko działało tak że można by zbudować prostego pilota ale przy próbie przesłania danych nic z tego, być może należało by spróbować z innymi wartościami elementów oscylatora w tych układach, co jednak jest kłopotliwe. Inaczej wyglądała sytuacja z wykorzystaniem gotowego polecenia Bascoma sendrc5. W takiej konfiguracji moduły działały świetnie przy bezpośrednim dołączeniu do mikrokontrolera z którego nóżki wejściowej wychodził gotowy zakodowany sygnał. Wadą był natomiast długi czas transmisji oraz sposób lub raczej “pojemność danych” w tym poleceniu, przesłanie całych bajtów nie wchodziło w grę a dzielenie bajtów na dwa i potem ich łączenie znów wydłużało by czas transmisji. Pozostawało przygotowanie własnego protokołu kodowania lub jakaś jeszcze inna opcja. Po wielu kombinacjach i próbach bo nie myślcie że temat był wałkowany tylko przez jeden wieczór, okazało się że jak zwykle najlepszym rozwiązaniem jest to najprostsze i przyszło mi do głowy równie nagle jak skuteczne się okazało, mianowicie wystarczył inverter sygnału na jednym tranzystorze(bramce logicznej), który załatwia sprawę bezpośredniego dołączenia nadajnika/odbiornika do UARTu. Za pomocą dwóch płytek testowych jednej z ATmegą8 a drugiej z Atmegą32 i rozdzielonej płytki stykowej na część z nadajnikiem i odbiornikiem radiowym przeprowadziłem próby przesyłania danych. Z portu szeregowego programem testowym wysyłałem kilka bajtów do jednej ATmegi(lub bezpośrednio do modułu nadawczego) i odbierałem je odbiornikiem radiowym dołączonym do drugiego mikrokontrolera który dane wyświetlał na LCD. Aby potwierdzić poprawność transmisji skorzystałem nawet z oscyloskopu przy czym stwierdziłem że przebieg danych po stronie nadawczej i odbiorczej nie odstają znacząco od siebie. Prędkość transmisji jaką próbowałem to 4800bps i 9600bps, nie wykluczone że poszła by jeszcze większa choć pewnie z błędami ale po co skoro nawet 4800bps jest tu wystarczające. Pozostałe ustawienia transmisji jak parzystość czy bit startu ustawione były domyślnie. Widać zatem że dobrym wyborem był zakup lepszej(i droższej) pary nadajnik odbiornik, świetna sprawa i wystarczające rozwiązanie, zwłaszcza że nadal można dorobić programowe kodowanie. Przekłamania w transmisji zdarzają się czasem, jednak zabezpieczona jest ona algorytmem sumy kontrolnej CRC. W przypadku odebrania błędnej ramki jest ona odrzucana. Dane odbierane są przez moduł RRFQ1 i interpretowane przez mikrokontroler, który zajmuje się wysterowaniem 10 serw(w sumie 9 kanałów) oraz włączaniem oświetlenia kamery. Na płytce odbiornika umieszczono też blok przetwornicy zbudowanej na układzie MAX761 która dostarcza zasilania dla kamery bezprzewodowej, myślałem na początku o MC34063 ale układ firmy MAXIM okazał się prostszy i zatem lepszy jak na stawiane mu wymagania. Ma on wydajność 150mA przy napięciu 12V. Kamera zaś pobiera tylko 70mA. Zasilanie dla manipulatora stanowi umieszczony wewnątrz akumulator żelowy o napięciu 6V(idealne do bezpośredniego zasilania serw) i pojemności 12Ah. Taka pojemność gwarantuje bardzo długą pracę, nie precyzuje jak długą by nie skłamać a trudno określić pobór średni prądu, wystarczy jedynie fakt że akumulator do tej pory musiałem ładować tylko raz, przed obroną. Dla części cyfrowej czyli mikrokontrolera i odbiornika radiowego zasilania dostarcza stabilizator o niskim spadku napięcia. Standardowy 7805 nie spisałby się tu(6V->5V). OPROGRAMOWANIE Specjalnie do obsługi manipulatora powstał program napisany w Delphi Enterprise 7. Miałem bowiem wcześniej z Delphi doświadczenie na uczelni lecz tylko przez jeden semestr. W ciągu kilku długich nocy przy pomocy poradników z internetu, starych pisanych na zaliczenie programów a zwłaszcza forum 4proggramers przypomniałem sobie co i jak i ściągnąłem potrzebne komponenty. Program bazuje na trzech głównych zadaniach, odbiór obrazu z urządzenia video zainstalowanego w systemie(kontrolka dspack), obsłudze urządzenia kontrolera gier(powerdraw) oraz transmisji danych przez port COM(cport). Wczesna wersja oparta była jedynie o wysyłanie danych przez port i obsługę urządzenia video. Wersja 1.0 obrazowała już stan wysterowania poszczególnych serw, natomiast wersja obecna, udoskonalona jest między innymi o graficzną reprezentacje położenia ramion, dzięki czemu obsługujący widzi na bieżąco jak wygląda położenie kolejnych stopni swobody. W programie znajduje się również prosty panel konfiguracji(wybór portu, kamery, joypada) oraz krótka instrukcja obsługi wraz z funkcjami klawiszy. Oprogramowanie dwóch mikrokontrolerów ATmega8 powstało w Bascomie(wiem jaki jest Bascom) ale póki co wywiązał się jeszcze ze stawianych mu wymagań. Najbardziej bałem się sterowania taką ilością serwomechanizmów, zwłaszcza przy obsłudze UARTa oraz kilku innych zadań, chociażby timera odmierzającego czas. Zastosowałem szybki kwarc co jest zalecane przy większej ilości serw. Program realizuje też funkcje samokontroli czyli na bieżąco co około 4 sekundy bada stan napięcia akumulatora oraz siłę sygnału, by nie dopuścić do nadmiernego rozładowania akumulatora(żelowe tego nie lubią) oraz nie stracić zasięgu ze sterowanym pojazdem który pomknął by w wiadomym tylko sobie kierunku KAMERA BEZPRZEWODOWA Jeszcze chciałbym dodać kilka słów na temat użytej kamery bezprzewodowej. Jest to miniaturowa kamera kolorowa z dźwiękiem pracująca na częstotliwości 2,4GHz. Najważniejszą jej zaletą jest to że odbiornik, nie tak jak w przypadku tańszych modeli z wyjściem AV, posiada gniazdo którym podłączany jest bezpośrednio do portu USB!! Na początku myślałem o zwykłej tańszej kamerce bezprzewodowej 1,2GHz z odbiornikiem wyposażonym w złącza AV, jednak musiałbym zastosować do laptopa z którego przewidziałem sterowanie jakąś kartę wideo/tuner na port pcimcia. W sumie wyszło by niewiele taniej a doszedł by problem z zasilaniem odbiornika z USB(znów przetwornica). Dlatego idealnym wręcz wyjściem był zakup modelu z interfejsem USB a dodatkowo 2,4GHz oraz brak strojenia wyszedł zdecydowanie na plus. Jedynym można powiedzieć małym i nieznaczącym w zasadzie minusem a zarazem plusem tej wersji kamery jest odrobinę większa obudowa w porównaniu do modeli z małą czarną kostką, za to dzięki temu że jest nieznacznie większa, umieszczono w jej obudowie diody oświetlające w ilości 6szt. Radość nie trwała zbyt długo gdyż okazało się że są to jedynie 3mm atrapy diod. Nie był to problem gdyż wystarczyło rozebrać obudowę i podmienić atrapy na prawdziwe LEDy. Zastanawiałem się jakich użyć, podczerwonych czy zwykłych białych(wchodziła też w grę wersja mieszana, podczerwone do akcji w nocy i zachowania niewidzialności) jednak jak się okazało, podczerwień nadaje się głównie do kamer czarno białych, a ta jest kolorowa(więc posiada filtr IR). Wybór zatem padł na 6szt bardzo dobrej jakości diod białych 3mm, połączonych równolegle każda z rezystorem i zasilanych z 5V(bezpośrednie zasilanie z akumulatora mogłoby powodować ich denerwujące przygasanie). Gotowa kamera zamocowana została na obrotnicy i porusza się razem z nią a dodatkowo w płaszczyźnie góra dół dzięki małemu modelowi serwa TowerPro. Jeśli ktoś jest zainteresowany mam dostęp do tych kamer w cenie dużo tańszej niż są oferowane na znanym serwisie aukcyjnym. MOŻLIWOŚCI ZMIAN Jak każdy potrafi sobie wyobrazić manipulator może mieć wiele ciekawych zastosowań, jest też możliwa jego rozbudowa o nowe systemy czy możliwości. Z modyfikacji elektroniki, warte uwagi było by dodanie kanału zwrotnego, tak się złożyło że urządzenie póki co go nie posiada. Jego zastosowanie pozwoliło by na przesyłanie do stacji bazowej wszystkich informacji z otoczenia manipulatora, przede wszystkim parametrów życiowych czyli stan akumulatora oraz siły zasięgu, aż po bardziej zaawansowane jak w wersji ekskluzywnej nawet licznik Geigera-Mullera . Nie ma powodów by narzekać, jednak modyfikacji można by poddać konstrukcje mechaniczną a dokładnie tylko napęd w celu zwiększenia mocy i właściwości trakcyjnych, wystarczy wymiana dwóch serw napędzających gąsienice. W grę oczywiście wchodzi dalsze udoskonalanie oprogramowania, przede wszystkim zmiana języka w jakim zostały napisane programy do mikrokontrolerów na taki, który daje większe możliwości, zwłaszcza gdy oprogramowanie mikrokontrolera będzie miało więcej do zrobienia. Także nowe funkcje programu sterującego np. możliwość elastycznego przypisania klawiszy czy to klawiatury czy dołączonych kontrolerów do funkcji urządzenia, bądź dodanie rejestracji obrazu z kamery w postaci pliku wideo zapisywanego na dysk, co jest do wykonania bardzo prosto i przewiduje prace właśnie w tym kierunku. Może ktoś z was ma jakieś pomysły czy sugestie, są one ograniczone w zasadzie tylko wyobraźnią Mogę dodać iż z wprowadzonych już zmian w stosunku do pierwotnie zakładanej wersji w modelu zmieniłem jedno serwo, konkretnie S11 na wersje metalową, gdyż plastikowa uległa uszkodzeniu i to co ciekawe nie przy pracy tylko przy ręcznym poruszaniu obrotnicą(przekładnie nie lubią takich sił), oraz wprowadziłem już kilka poprawek do programu mikrokontrolera części odbiorczej, generalnie szczegółów. Jak na chwile obecną manipulator jest w pełni gotów do zadań specjalnych. KOSZTORYS Lub może lepiej nie... Tym razem mogę przedstawić dokładniejszy kosztorys zwłaszcza głównych elementów konstrukcji gdyż zbierałem wszystkie faktury lub inne dokumenty z ceną gdy nie dało się wystawić faktury. Ceny które podaje zawierają podatek VAT oraz koszty przesyłki, serwomechanizmy i podzespoły elektroniczne były przykładowo zamawiane w kilku partiach. Oprócz kosztów napiszę skąd pochodziły konkretne elementy czy podzespoły, pomoże to zainteresowanym w zakupie. Serwomechanizmy (SOMMERTECH, NASTIK - polecam!!, AIRHOBBY) – 699zł Podzespoły elektroniczne (TME) – 301zł (nie wszystkie wykorzystane) Kamera bezprzewodowa – 293zł Laminat (MERKAR - polecam!!) – 185zł Moduły radiowe Telecontrolli (SOYTER - polecam!!) – 154zł Ładowarka akumulatora (AKBA) – 79zł Akumulator żelowy (AKBA) – 53zł Komplet śrub nakrętek i podkładek M3 – 31zł Powyższy spis i tak wydaje się zbyt mały, owszem nie przedstawiłem w nim cennika części na które nie mam dokumentacji, chociaż też kosztowały swoje, chociażby gąsienice z uszkodzonego modelu czołgu czy materiały potrzebne do wykończenia i inne drobnostki, jednak i bez tego suma jest piorunująca. Każdy zsumował powyższą listę?? Ktoś uważa że przepłaciłem za inżyniera ??? PODZIĘKOWANIA Chciałem podziękować kilku osobom z elektrody za pomoc, gdy była ona potrzebna do rozwiania moich wątpliwości lub wyjaśnienia jakiegoś zagadnienia. Koledze mirekk36 za fachowe wytłumaczenie zasad kodowania sygnałów i próby rozwiązania transmisji bezprzewodowej za pomocą modułów radiowych. Widać że często udziela się w dyskusjach i na jedną z nich na interesujący temat transmisji bezprzewodowej niegdyś trafiłem. Po wielu różnych próbach gdy znalazłem w końcu rozwiązanie bezpośredniego dołączenia modułów radiowych do UARTu oczywiście z odwróceniem sygnału, kolega przetestował je nawet osobiście. Dzięki za pomoc i korespondencję!! Koledze yego666 za informacje na temat jego interfejsu sterownika serwomechanizmów który kiedyś stworzył a przede wszystkim za słowa “nic wiec tam nie ma czego przeciętnie zdolna małpa by nie opanowała” co naprawdę solidnie natchnęło mnie do działania i jak widać powstał bardzo dobry program w Delphi a szczerze jeszcze rok temu myślałem, że właśnie z tym będę miał problem nie do przeskoczenia. Dziękuje za to wsparcie bo przydało się!! Koledze radziow za pomoc w temacie http://www.elektroda.pl/rtvforum/topic981853.html , miałem bowiem pomysł jak to zrobić od strony rysowania ale nie miałem pomysłu na samo wyznaczenie współrzędnych co widać nie było aż takie trudne. Czasem utknie się jednak na najprostszym etapie i trzeba jakiegoś impulsu a mi się musiało myślenie chyba zawiesić, dzięki za pomysł!! DO POBRANIA A teraz czas na obiecany deser – poniżej materiały jakie narazie przygotowałem. Po ściągnięciu pracy zalecam wygodnie rozsiąść się w fotelu, myślę że czytać będzie się miło. W paczce ze zdjęciami znajdują się wersje w lepszej jakości, dodatkowo są też zdjęcia nie zamieszczone w samej pracy, polecam ściągnąć choć dużo tego. Dla dociekliwych program wraz z instrukcją obsługi do wglądu a dzięki filmikom z pracy manipulatora będzie można poczuć się jak operator. Materiały part1 – http://www.speedyshare.com/913539449.html Materiały part2 – http://www.speedyshare.com/507441140.html Ponadto dzięki uprzejmości kolegi manekinen z forum elektroda.pl, całość materiałów można ściągnąć z jego serwera pod adresem poniżej. Dziękuję za udostępnienie miejsca! Materiały całość - www.mm.pl/~kisiel-ket/manipulator.rar Ponadto aby był wgląd w zdjęcia przygotowałem jednak tabele z miniaturami, którą zamieszczam tutaj, po ich powiększeniu da się dość dużo zobaczyć. I oczywiście jeden z filmików, zamieszczam na YouTube tylko jeden gdyż drugi przedstawia działającą aplikacje i żeby było cokolwiek widać warto go ściągnąć. Link - SŁOWEM ZAKOŃCZENIA Znam umiejętności czytania tekstu ze zrozumieniem co niektórych, zapraszam więc do komentowania i do zadawania pytań, tylko proszę nie takich na które odpowiedź można znaleźć w powyższym tekście bądź w samej pracy, naprawdę wszystko jest dość szczegółowo opisane. Mile widziane uwagi oraz nowe pomysły lub sugestie. Gdyby były wątpliwości model nie jest na sprzedaż, jednak jeśli czyta to ktoś z powiedzmy NASA lub służb specjalnych to rozważę wszelkie propozycje dobrej współpracy Dziękuję za poświęcony czas. Pozdrawiam Janek
  16. 11 punktów
    Normalną sprawą jest że zawsze zaczyna brakować wolnych portów w mikrokontrolerze, standardowe podłączenie LCD to 6 pinów , dlatego powstała wersja z wykorzystaniem magistrali I2C oraz popularnego układu PCF 8574 . Wykorzystując ten układ zrobiłem płytka dla wyświetlacza LCD i klawiatury matrycowej 4x4 nie będę opisywał tego rozwiązania ponieważ wszystko jest na stronie http://www.mcselec.com/ AN#118 z dokładnym opisem i przykładami, w nowej wersji Bascoma są już zainstalowane potrzebne biblioteki dla starszych należy je ściągnąć. Proponowane rozwiązanie z magistralą I2C pozwala obsłużyć wyświetlacz i klawiaturę zajmując tylko dwa piny mikrokontrolera. Oba układy posiadają możliwość pełnego adresowania (zworki) w przypadku kiedy z góry ustalimy sobie adresy nie ma konieczności montowania goldpinów wystarczą odpowiednie mostki. Wszystkie prezentowane układy zostały wykonane, przetestowane i nie ma żadnych problemów z ich uruchomieniem przy prawidłowym montażu, napisano programy testujące i tak należy je traktować są to tylko proste przykłady aby sprawdzić poprawność pracy prezentowanych rozwiązań układów, oczywiście można zawsze dostosować je do własnych potrzeb. W czasie testów wykorzystałem prymitywny układ z silnikiem DC oraz enkoderem jako czujnik wykorzystałem transoptor szczelinowy pochodzący z starej drukarki. W dwóch programach zastosowano typowe połączenie LCD w różnych konfiguracjach podłączenia wyświetlacza i mostka H w trzecim z wykorzystaniem magistrali I2C z obsługą wyświetlacza i klawiatury, w tym miejscu podkreślam jeszcze raz to tylko mój sposób podłączenia. Uwagi Dla jasności i przejrzystości głównie programowej zastosowałem podobne rozwiązania jak poprzednio czyli wejścia sterujące danego układu są po kolei jednak to tylko przykład i można sobie w dowolny sposób dokonać własnego podłączenie. Proponuje jednak tak wszystko sobie rozplanować aby istniała możliwość wykorzystania sprzętowych możliwości mikrokontrolera tzn wejścia komunikacyjne, przerwania, pwm, przetwornik analogowy oczywiście istnieje zawsze możliwość programowego napisania obsługi ale nie wszystkiego a dla początkujących łatwiej będzie wykorzystać to co daje producent. Dla tych którzy wykonują układy z zdjęć (są tacy) a nie z schematu informuję że z płyty głównej usunąłem złącze dla zewnętrznego napięcia odniesienia, na płycie LCD_I2C są dodatkowe rezystory podciągające magistralę I2C, projekty pcb są już z tymi zmianami, płytki z LCD posiadają zworkę do włączania podświetlenia, które nie zawsze jest potrzebne dodatkowo umieszczony jest rezystor ograniczający należy przed uruchomieniem podświetlenia sprawdzić na jakie są napięcia pracy diody ponieważ są różne wersje. Układy filtracyjne składają się z kondensatora EL i stałego (najlepiej ceramiczny) najczęściej są one umieszczone obok siebie i nie ma znaczenia który jest pierwszy, ważne jest aby były zastosowane, najważniejsze przy mikrokontrolerze ( jak najbliżej ) oraz przy stabilizatorze napięcia. Pliki do pobrania (lub z załączników powyżej): • schematy nowej płyty głównej • projekt płytki nowej płyty głównej • programy nowej płyty głównej Możliwości rozbudowy jest wiele, może ktoś na forum przedstawi kolejne etapy rozbudowy, zaproponuje inne moduły w robocie, moim celem było pokazanie w jednym temacie podstawowych zagadnień związanych z budową własnego robota, temat adresowany jest głównie dla początkujących, dlatego nie ma tu jakiś specjalnych bajerów. Zdaję sobie sprawę że nie sposób opisać wszystkiego, myślę że ten temat coś powinien pomóc przy budowie swojego pierwszego robota. Dziękujemy autorowi za zgodę na publikacje artykułu na diodzie. Jeśli po przeczytaniu, nie wiesz jak coś działa lub jak coś wykonać użyj wyszukiwarki!, jeśli zapytasz o coś co było już opisywane na forum - post zostanie usunięty. Inne pomocne tematy: • Najczęstsze problemy początkujących • Przerabianie serwomechanizmów • Kurs BASCOM-AVR • Częste błędy początkujących
  17. 10 punktów
    Witam, chciałbym przedstawić robota klasy Line Follower, będącego jednocześnie moją pierwszą konstrukcją. Miał to być prosty robot, który z mniejszym lub większym powodzeniem będzie w stanie poruszać się po linii. Założenia projektowe zmieniły się jednak z biegiem czasu i ostatecznie Serdel wystartował na turnieju Robomaticon w Warszawie zajmując tam 8 miejsce oraz na Robot Challenge, gdzie odpadł w jednej ósmej finału. Mechanika Robot zbudowany jest w oparciu o odpowiednio przycięte i połączone śrubkami kawałki laminatu będące kolejno podwoziem, nadwoziem utrzymującym elektronikę, płytką z czujnikami. Napędzany jest silnikami Pololu HP 30:1, na których wały założono koła tej samej firmy o średnicy 32mm. Z powodu słabej przyczepności ich opon zostały wymienione podczas Robot Challenge na koła odlane z poliuretanu. Elektronika Płytka została zaprojektowana oraz wykonana przeze mnie techniką montażu przewlekanego. Mózgiem robota jest mikrokontroler ATmega88. Do sterowania silnikami wykorzystano mostek L298, co uważam za największy błąd w projekcie. Spadek napięcia sięgający 2V skutecznie uniemożliwia wykorzystanie pełnej mocy silników. Z przodu robota znajduje się 5 czujników linii CNY70 ułożonych w kształt litery V, z których odczyt przekazywany jest do przetwornika analogowo-cyfrowego mikrokontrolera. Po czasie stwierdzam, że jest to zbyt mała ilość czujników. Robot zasilany jest pakietem dwoch ogniw litowo-polimerowych firmy Kokam o pojemności 640mAh. Algorytm Program napisany został w całości w języku C. Robot wykorzystuje algorytm regulacji PD. Zdjęcia Podsumowanie Jestem stosunkowo zadowolony z przedstawionej konstrukcji, mimo iż nie jest ona pozbawiona wad. Przy projektowaniu opisanego robota wiele się nauczyłem i nabrałem doświadczenia, które wykorzystane zostanie przy kolejnym, bardziej już złożonym projekcie, mającym miejmy nadzieję szanse na lepsze osiągi. Chętnie odpowiem na wszelkie pytania.
  18. 10 punktów
    Przyznaje się do popełnienia światłolubnego robocika (opis zamieszczam na prośbę jednego z adminów). Przed jego wykonaniem, popełniłem "Waldka Światłoluba", którego opiszę w kolejnym temacie, a teraz przedstawiam robocika od którego już tylko krok do zbudowania w pełni oprogramowanej "besti" : Do budowy potrzebna będzie: - serwa modelarskie sztuk 2 (użyłem tanich 9 gramowych serw zakupionych na aukcji - cena ok 17,00 zł /szt.) - płytka uniwersalna lub wytrawiona wg rysunku - 4 akumulatorki 1,2 V - koszyk na akumulatorki (ok 1,50 zł) - 2 koła (również aukcja - cena ok 4,00 zł/szt) - kółko (ja użyłem z drukarki, niestety nie wiem z jakiej chyba Canon?) - wyłącznik - układ L293DNE (cena od 3,50 zł do 9 ,00 zł) - podstawka pod układ - rezystory 220 Om sztuk 6 - diody led sztuk 4 - dowolne fototranzystory(cena od 0,60 zł do 3,00 zł) - hot glue - lub inny dowolny klej Latarka lub inne źródło światła. Czas pracy ok. 3 godzin. Oczywiście serwa zostały "lekko" zmodyfikowane: - usunięta została elektronika - usunięty został plastikowy element ograniczający obrót serwa Czyli "standardowa" modyfikacja modelarskiego serwa na potrzeby robotyki Proponuję "zalać" klejem elementy narażone na zderzenia z przeszkodami (LED oraz fototranzystory), na pewno przedłuży to żywotność ścieżek na płytce. Wszystko opiera się na podstawowym pomocniku zarówno początkującego jak i mocno zaawansowanego robotyka, układzie: L 293, a zdjęcia i film wyjaśniają wszystko. Mam nadzieję, że jako nowy użytkownik nie naruszyłem żadnych zasad - a przynajmniej bardzo starałem się by ich nie naruszyć, oraz że moje a właściwie nasze robociki których głównym konstruktorem jest mój 6 letni syn zostaną ciepło przyjęte krótki filmik : zdjęcia wyjaśnią resztę:
  19. 10 punktów
    Witam, chciałbym zaprezentować mojego robota minisumo: Skynet. Robot powstał już 2 lata temu, był od tego czasu nieco ulepszony, ale może po kolei. 1. Konstrukcja Jest to typowa "kostka" na serwach MG995 dających potężny moment (jak na minisumo), przerobionych poprzez wyciągnięcie elektroniki, blokady i potencjometru. Koła to nakrętki 90mm oklejone uszczelką do okien (na drewnianych ringach spisywała się znakomicie, na plastikowych niestety już średnio). Początkowo do podpierania służyły dwie diody LED, po których robot się ślizgał, niestety był to kiepski pomysł, gdyż po upadku ze stołu na zawodach diody się połamały i robot się pochylił. W kolejnym roku jako podpórka służyło już kółko z magnetofonu widoczne na jednym ze zdjęć. Projekt był robiony w programie Inventor, jednakże na żywo okazało się, że trzeba wprowadzić pewne modyfikacje: Początkowo robot posiadał jeden czujnik analogowy Sharpa, w obecnej konstrukcji posiada 2 czujniki cyfrowe Sharpa oraz czujniki na bazie TSOP1736. Całą konstrukcja jest wykonana z laminatu miedzianego i polutowana = robot jest bardzo wytrzymały mechanicznie - przeżył już wiele upadków. Niestety w połączeniu z gęstwiną kabli robot jest przez to po prostu brzydki Ze względu na duzy moment, przy maksymalnej prędkości robot ma dużą bezwładność korpusu i może się przechylać do tyłu (pomimo klapek z przodi), dlatego tył ma tak ukształtowwany, aby sie podparł. W takim wypadku zamiast się przewrócić, zaprze się (przynajmniej w teorii). W praktyce działa to tylko na roboty, które nie pozwalają się przewrócić klakami, ale zostały nimi zaczepione - efektem jest remis. Najbardziej oryginalna część jaką są klapki znakomicie działają na roboty z płaskim, niesbyt ostrym przodem - czyli przede wszystkim inne kostki, ale na niskie roboty z płaskim przodem też działa świetnie - przykłądowo sparingi z ubiegłorocznym zwycięzca wygrywał, bo ten miał płaski przód, a jego klinoklapka była trzymana z dala od Skyneta dzięki moim "klapko-przewracaczom". Takie papier-kamień-nożyczki, w którym ten robot mozę pokonać dobrego robota a zostać zmasakrowanym przez przeciętnego Robot w obecnym kształcie waży 499g. 2. Zasilanie Robot początkowo był zasilany z 4 ogniw z telefonó komórkowych poąłczonych 2x2 - czyli maksymalnie 8.4V przy pełnym naładowaniu. Potem zrezysnowałem z tego pomysłu, gdyż w momencie keidy siadało napięcie, odczyt z analogowego Sharpa był zakłamywany (AVcc = Vcc), poza tym bałem sie resetowania. Obecnie jest zasilany z 3 ogniw (czyli 12V), elektronika ma zsilanie stabilizowane na LM7805 - przy 12V na wejściu trochę sie nagrzewa, dlatego ma naklejony radiatorek. Całe zawody mógłby jeżdzić bez ładowania 3. Elektronika Mózgiem elektroniki jest mikrokontroler ATmega8 taktowany z częstotliwością 8MHz. Mostek H został wykonany na pojedynczym przekaźniku + mosfecie, z zabezpieczeniem w postaci diody schottkyego. Wszystkie nóżki zostały wyprowadzone. Na pokładzie jest równeiz obsługa czujników linii, które niestety okazały się potwornie zawodne (były powodem totalnej klapy rok temu), dlatego postanowiłem je zupełnie zignorować i tak zmodyfikowałem program, aby nie były potrzebne. Na schematach nie ma wszystkiego - kolejen elementy dokładałem wykorzystując wyprowadzone piny, a nawet złącze od programowania. W ten sposób dołożyłem 3 diody informacyjne, oraz czujnik na bazie TSOP1736. Kabelkó też trochę doszlo 4. Czujniki Jak już podałem, początkowo robot posiadał: - jeden Sharp analogowy na 70cm - pożyczony, więc musiałem oddać - 2x CNY70 - awaryjne, więc odłączyłem ich wtyczki od elektroniki - 2x krańcówki z tyłu wykrywajace atak od tyłu - nieprzydatne, bo przy ataku od tyłu i tak było już po ptakach, więc je usunąłem Obecnie: - 2 czujniki cyfrowe Sharp na 40cm - działa ładnie, ale tylko do przodu - jeden TSOP1736 + 2 diody nadawcze - działa dobrze, ale ma słaby zasięg, który musiałem ograniczyć aby uzyskać pewność odczytów - jakieś 20cm, na ukosy Robot niestety ne posiada żadnych czujnikó na boki, co jest spowodowane duzymi kołami - i bardzo mnie to boli, ale nie da się na to nic poradzić 5. Algorytm Początkowo kombinowałem, aby wykorzystując jeden czujnik robot miał duży kąt idzenia, dlatego robot jeździł wężykiem omiatając wszystko co ma przed sobą. Działało to nieźle, ale było słabe dynamicznie. Mimo to bylo ok. W momencie, kiedy wyłączyłem czujniki linii robot szaleńczo sie kręci i - kiedy widzi na ukos, obraca się w tamtym kierunku - kiedy widzi z przodu, szarżuje Ot i koniec inteligencji robota 6. Zady i walety: + klapka działa, przerwaca albo chociaż powstrzymuje przeciwników + robot był tani - nawet wliczajac czujniki, zmieściłem się w 170-180zł + robot jest wytrzymały, jestem przekonany, że jak go odpalę za rok dalej będzie działał i jeździł + jest agresywny + budzi zainteresowanie - szczególnie zabawnie wyglądał, keidy szwankowało mu sterowanie i objeżdżał butelkę stojącą na środku ringu (jakiś zawodnik stojący obok rzucił "Eee, Macarena" z Innych cytatów: "Gdzie on ma przód" i "Jest tak brzydki, że tylko jego matka by go pokochała" - kołysze sie podczas jazdy, niestety przy tym momencie jaki mają serwa, łatwo się przechyla do tyłu, to uważam za dużą wadę - nie ma czujników po bokach - jest wysoki Poniżej trochę zdjęć, jak znajde, wrzucę filmiki. Ew. jakiś zrobię na szybko. Jeśli chcecie program też mogę wrzucić, tylko poszukam. Z dwóch profili: Nierozłożony: Rozłożony: Gęstwina kabli: Czujniki: Spód i czujniki linii: Redi tó fajt: Cytując jednego z widzów z zawodów we Wrocławiu: "A gdzie on ma przód?" __________ Komentarz dodany przez: Treker Proszę następnym razem nie dodawać zdjęcia na samym początku.
  20. 9 punktów
    Witam, przedstawiam wam Pępka3 - robota klasy minisumo na modelarskich silniczkach klasy powiedzmy 260 (kupione jako 280 za 5zł, ale Sabre wyprowadził mnie z błędu, obawiam się, że nawet 260tkom nie dorastają do pięt). Elektronika - bardzo prosta płytka główna na m8, prawdę mówiąc nie ma nawet mostka H, tylko dwa mosfety 079N03 - po zawodach w Krakowie stwierdziłem, że jak na razie i tak nie wykorzystałbym możliwości mostka, mój inny minisumo, z którym byłem również nie jeździł do tyłu a zaszedł aż do baraży (co patrząc na to, że Litwińskie roboty stanowiły chyba 1/4 robotów minisumo i na to, że był na silniczkach 95RPM oraz był zbudowany w 7 godzin było wynikiem niezłym). Z tego powodu nie montowałem nawet czujników linii (a może nie dodawałem jazdy do tyłu, dlatego, że nie montowałem czujników linii , bo jaki byłby w tym sens - żaden. Na płycie znajduje się też kilka (mianowicie 4) diod, i złącze ISP (tak, nie ma bootloadera USB, kórego zawsze i wszędzie zachwalam ). Do wykrywania przeciwnika służą 2 cyfrowe Sharpy GP2Y0D340K - miłe czujniczki, naprawdę polecam. Zasilanie pochodzi z 'pakieciku' dwóch lipolków 400mAh 15C, zakupionych ongiś na allegro w bardzo fajnej cenie. Tak, pasowałaby wyższa pojemność patrząc na prądożerstwo silników (nawet 5-6A w zatrzymaniu - tak, to NA PEWNO nie są 260, może nawet są na jakieś niziutkie napięcie, ale co tam, dostają te 7-8V - kręcą się dzięki temu prawie 23000 RPM - obroty na kole ~635RPM), ale podczas zwykłego toczenia po dohyo robot pobiera ~600mA, a atakując (pchając) to szczerze nie mam pojęcia, ale szacuję, że około 4-5A. Jak na razie robot toczy się swobodnie przy PWM 150, a atakuje 200 - muszę jeszcze dopracować kod. Mechanika - jak już wyżej wspominałem, napędzane toto jest przez dwa silniki 'modelarskie', a cały robot opakowany jest w puszkę z mosiądzu 0,7mm, pokrytą czarnym matem. Kółka toczone ze stali (również pokryte czarną farbą), przekładnia niestety z tworzywa (zębatki WObitowskie), obudowana 'ceownikiem' z laminatu. Pług jak praktycznie cała obudowa również został wyprofilowany z kawałka blaszki mosiężnej. Może całość nie wygląda, ale jest konstrukcją zwartą. A teraz kilka zdjęć, zarówno z budowy (i pierwszej wersji płytki, niestety niedziałającej) jak i ukończonego robota, na schnącym jeszcze dohyo (filmiki jakieś wrzucę jak wyschnie ) i kilka obiecanych filmików (wybaczcie jakość, wysokie iso w aparacie niestety obszumiło wszystkie klatki): tutaj jakieś takie niezidentyfikowane buksowanie kołem - nie zębatką na ośce, nie wiem czym to było spowodowane.
  21. 8 punktów
    Witam. W wolnej chwili postanowiłem opisać konstrukcję diy segwaya. Myślę ze można go zaliczyć do kategorii robotów i opisać na tym forum. Zrobiliśmy z kolega 2 szt żeby nie było niejasności z prawami do użytkowania między nami. Wykonane zostały w tamtym roku i do tej pory jeżdżą. Krótki opis: - Konstrukcja stalowa, elementy wycinane laserowo z blachy ok 1,5mm. Całość ocynkowana. - Koła w jednym modelu od taczek , w drugim alusy od skutera - Elektronika - wheelie 2. Zmiany jakie wprowadziłem to dołożyłem i oprogramowałem wskaźnik baterii oraz zrobiony na nim balance indicator dzięki któremu zawsze w tej samej pozycji można na segwaya stanąć. Dodatkowo dołożyłem moduł BT żeby na bieżąco monitorować na laptopie parametry. Dodatkowo oprogramowałem czujniki prądu ACS ( w oryginale wcale nie są oprogramowane). Dzięki temu blokując koła nie palą się od razu tranzystory w driverach tylko płynie max koło 40A. Dodatkowo zamiast czujników hala na zębatkach zastosowałem zrobione z tcrt5000 czujniki optyczne włożone do wnętrza silnika. Doświadczalnie też dołożyłem żyroskop osi z i wstępnie oprogramowałem. Dzięki temu zjazd jednym kołem z jakiegoś krawężnika czy jakieś inne obniżenie czy podwyższenie stabilizuje obrót. - Drivery - również ze schematu wheelie 2 z lekkimi modyfikacjami. - Napęd - 2 tanie silniki 500W 24V napędzające poprzez przekładnie chyba 11/80 zębów i łańcuch. Testowaliśmy też z przekładniami zębatymi wykonanymi na laserze ale głośność i drżenie były poza granicami akceptowalności. - Zasilanie 2 akumulatory żelowe 12V 20Ah. Na początku planowaliśmy li-ion'y lub li-pol'e ale z racji ceny nie do pobicia stanęło na żelówkach. Co to dużo gadać. Zapraszam do oglądnięcia kilku fotek oraz filmiku.
  22. 8 punktów
    Nie ma co robić wstępów. Jeśli zostaną tu przeniesione posty z innego wątku, przyczyna przeprowadzenia tych pomiarów będzie jasna. Po pierwsze: Xweldog - masz rację, jeśli chodzi o Twoje doświadczenie. Przypomnę, że chodziło o sterowanie silniczka DC mało wypełnionym PWM i obserwację spadku mocy ze wzrostem częstotliwości. Tak, to prawda. Dopatrywałem się w tej próbie jakiejś nierzetelności lub niezawinionego błędu ale teraz potwierdzam, wszystko było OK. Twój silniczek słabł i mój, obciążony śmigłem zwalniał także. Tylko że.. ale o tym za chwilę Teraz o wynikach moich dzisiejszych badań. Na warsztat wziąłem szczotkowy silnik Graupnera klasy 400, 7.2V z typowym dla tych motorków śmigłem Gunthera. Zbudowałem prosty modulator PWM na jednym tranzystorze MOSFET, diodzie Schottky włączonej równolegle do silnika i driverze IR2184 sterującym bramkę tranzystora. Driver (a więc i bramka) zasilany był z osobnego zasilacza +12V. Obwód główny - silnik + MOSFET dołączyłem do zasilacza 30V/20A żeby mi mocy nie zabrakło Ustawiony był oczywiście na 7.2V. Dzięki takiej konfiguracji mogę prowadzić próby bez obaw, że przy różnych silnikach napotkam ogranicznia ze strony zbyt małego lub zbyt dużego napięcia sterowania bramki. Ustawiłem wypełnienie PWM=20% (na mniej nie pozwolił generator ) i poczynając od częstotliwości 20Hz mierzyłem obroty silnika i prąd. Po dojechaniu do 100kHz wracałem z powrotem do 20Hz zwiększając wypełnienie o 10% Oto uzyskany wykres: Z powyższych krzywych jasno wynika, że zwiększając częstotliwość PWM przy zadanym, stałym wsp. wypełnienia silnik wyraźnie zwalnia. Kiedy już zakończyłem zbieranie danych zacząłem się zastanawiać: no dobra, przecież ten przyrost mocy po lewej stronie nie bierze się z nikąd. I rzeczywiście - silnik pobiera po prostu większy prąd, więc i szybciej się kręci. To nie jest darmowe. Przy okazji uwaga: w ciągu całego eksperymentu zarówno tranzystor jak i dioda były zimne. Nie było niepotrzebnych strat i całość mierzonego prądu szła w moment mechaniczny. W wyższych częstotliwościach silnik zachowuje się jak cewka - i tu jest dokładnie tak jak się spodziewałem, ale w niższych jego "cewkowatość" zanika na rzecz czegoś innego. Podrążyłem trochę to zjawisko i wyszło mi, że "na przełomie", czyli w okolicach 1-2kHz następuje zmiana w charakterze płynącego prądu. Otóż powyżej tego progu prąd w silniku jest ciągły - tego się spodziewałem. Wygląda jak piła narastająca w czasie gdy PWM jest załączony i opadająca gdy napięcie na bramce klucza jest równe 0. Same zmiany prądu (amplituda piły) są oczywiście tym mniejsze im wyższa jest częstotliwość PWM. No i ta piła "buduje" swoją wysokość przy spadku częstotliwości coraz bardziej, aż w okolicy 2kHz dotyka zera. To oznacza, że pompowany do silnika w fazie "gorącej" prąd nie płynie już do nas z powrotem przez całą fazę zimną, tylko szybciutko rozładowuje się przez diodę i zamiera w zerze - bo ma dużo czasu. Natomiast w fazie "gorącej" udaje mu się narosnąć do 100% prądu znamionowego silnika. W moim przypadku było to ok. 7A. I to właśnie - jak się domyślam, jest przyczyną przyrostu prędkości obrotowej. Wirnik "kopnięty" pełnym prądem nawet w ciągu 20% całego okresu, obraca się szybciej niż zasilany stałym prądem o takiej samej wartości średniej. Tym bardziej, że w czasie fazy "zimnej" PWM nie jest hamowany przez cały czas prądem wypływającym. Przez dużą część okresu jedzie na energii kinetycznej. Po jakimś czasie spojrzałem na te wyniki trochę inaczej. No dobra, to teraz popatrzmy co mamy dla STAŁEJ częstotliwości. Trochę poprzestawiałem tabelki i wyszło mi to: To są dokładnie te same liczby, tylko inaczej narysowane. Okazuje się, że dla niskich częstotliwości ani silnik ani "mostek" nie mają jakichś magicznych osiągów. Po prostu nieliniowość regulacji jest tak wielka, że jeszcze przy 20% wypełnienia wolnego PWMa silnik kręci się całkiem żwawo. Na wykresie naniosłem też grubą czerwoną linią tryb regulacji DC. Podłączyłem silnik wprost pod zasilacz i zapodawałem napięcia DC będące odpowiednimi ułamkami (20-80% i 100%) napięcia znamionowego. To jest jakiś wyznacznik regulacji idealnej(?). Mostek pracujący na lub powyżej kilku kHz będzie regulował obroty bardziej liniowo. Ten na 200Hz będzie jechał z obrotami bardzo stromo na dole ale po przekroczeniu połowy zakresu zacznie się wypłaszczać i tam duże zmiany PWMa będą powodować już niewielkie zmiany szybkości. Nic nie zyskujemy ale też nie tracimy. Jeżeli algorytm żąda 1/3 momentu maksymalnego, to przy PWM 10kHz dajemy wypełnienie 33% i z głowy. Przy taktowaniu 200Hz musimy ten współczynnik wyliczyć na jakieś 10% - czy to lepiej czy gorzej? Nie wiem, osądźcie sami. Istotną sprawą są też zakłócenia impulsowe. W zakresie setek Hz modulator PWM jest generatorem potężnych impulsów obciążających akumulator. Tutaj było to 0 lub 7A - na zmianę. To dla akumulatorów wcale niemało. Podjechanie do 10kHz załatwia sprawę - prąd ma wartość ustaloną a wahania nie przekraczają 10%. Przyznaję, że zjawisko nieliniowości regulacji trochę mnie zaskoczyło ale wcale nie uważam, że dyskwalifikuje ono mostki pracujące na setkach Hz. Jeżeli ktoś w ten sposób świadomie skonstruuje regulator PWM korzystając z drivera zbudowanego "na piechotę" (bo wtedy można ) i ma sposób na walkę z zakłóceniami impulsowymi - to też będzie działało. Oczywiście mam świadomość, że dla innego silnika będzie trochę inaczej choć nie sądzę, by coś poważnie się miało zmienić. Zamierzam zrobić te same pomiary dla pozostałych moich eksponatów i wrzucić tu wyniki.
  23. 7 punktów
    Artykuł przeznaczony do wszystkich zapaleńców druku 3D. Można nie kupować dość drogi filament do swojej drukarki 3D, a produkować w domu własny filament z zużytych butelek PET od napojów. Przy tym nieważne, jeżeli butelka jest pognieciona, ona również się nadaje do domowej produkcji filamentu. Filament z butelek ma sporo zalet w porównaniu z firmowym filamentem kupowanym – ABS albo PLA. Przede wszystkim, że produkowany filament nic nie kosztuje, jest po prostu darmowy Produkowany pręt filamentu Jest bardzo sztywny i absolutnie nie łamliwy, wytrzymuje sporo ostrych przegięć. Filament własnej produkcji jest sporo mocniejszy i twardszy, jak na rozciąganie tak i o wiele bardziej odporny na uderzenie. Absolutnie nie pochłania wody, czyli nie trzeba go ani suszyć, ani chronić w zamkniętym zabezpieczonym od nawilżania się opakowaniu. Praktycznie nie skurcze się przy ochłodzeniu w trakcie druku. Nie wymaga chłodzenia drukowanej warstwy. Nie wymaga stołu podgrzewanego. Dla przyczepności wystarczy miejsce na stole posmarować cienką warstwą kleju w sztyfcie na przykład typu „Glue Stick” Wydrukowane detal można obklejać od razu po skończeniu wydruku. Taki filament jest bardzo odporny na działanie rozpuszczalników i środków chemicznych. Jak widać filament produkcji własnej ma sporo zalet w porównaniu z filamentami kupowanymi, a najważniejsze – że jest darmowy. Niżej przedstawiono zdjęcia maszynki do produkcji filamentu: Do domowej produkcji filamentu wykorzystywane zużyte butelki od napojów. Ale butelki muszą być czyste, resztki kleju do nalepki powinni być usuwane. Technologia produkcji jest bardzo prosta i składa się z trzech następujących operacji: Poprawa zgniecionych butelek i butelek z ryflowaną powierzchnią tak, żeby ścianka boczna butelki była gładka. Nacinanie butelek na paski o określonej szerokości, od 5mm do 12mm w zależności od grubości ścianki butelki. Produkcja pręta filamentu z nacinanych pasków na specjalnej maszynce z nawijaniem na bębenek odbiorczy. Na tych wideo można obejrzeć prace maszynki i przyrządu do nacinania pasków z butelek: Zębatka drukowanie:
  24. 7 punktów
    Jakiś czas temu na forum pojawiło się kilka wpisów krytykujących Raspberry Pi jako platformę sprzętową. Nie próbuję nawet wmawiać, że malinka jest idealna - jednak niektóre problemy można rozwiązać bardzo (albo chociaż dość) łatwo. Problemy o których piszę to np. zużywanie kart SD, długi czas uruchamiania płytki, problemy z systemem plików jeśli nagle odłączymy zasilanie, długi czas kompilacji programów, czy brak możliwości uruchomienia systemu z pamięci USB. Wiele z opisanych niedogodności wynika ze sposobu używania malinki. Większość osób stara się zrobić z niej mały komputer PC - i nie ma w tym nic złego, w końcu na Forbocie właśnie tak opisywaliśmy kurs Raspberry Pi. Jednak malinka nie we wszystkim może zastąpić komputer stacjonarny i czasem nieco inne podejście może dawać nieco lepsze rezultaty. Komputer stacjonarny, a komputer wbudowany Pierwsza istotna sprawa to rozróżnienie między rozwiązaniami wbudowanymi (embedded), a komputerem stacjonarnym (desktop/laptop). Urządzenia wbudowane są konstruowane do spełniania jednej, z góry określonej funkcji - przykłady to procesor w ekspresie do kawy, bankomacie, czy samochodzie. Oprogramowanie można aktualizować, nawet zmieniać na własne (tym zajmują się hackerzy), ale nadal program ma ściśle określone zadanie do wykonania. System ogólnego przeznaczenia, to nasze komputery stacjonarne lub przenośne - czyli zupełne przeciwieństwo wbudowanych. Można na nich grać w pasjansa, Wiedźmina, a nawet inne gry, przeglądać internet, pisać programy i robić miliony innych rzeczy. Instalacja nowych programów jest łatwa, niekiedy nawet udaje się je odinstalować. Arduino jest kolejnym przykładem platformy wbudowanej. Program kompilujemy na PC, wgrywamy na płytkę i ma on wykonywać to co sobie zaplanowaliśmy - migać diodą, sterować robotem, itd. Ale już nowych progamów nie dodamy, nie będziemy na Arduino kompilować kodu, ani grać w pasjansa (chyba że to jest główna funkcja naszego układu). Raspberry Pi natomiast jest najczęściej używane jako mały komputer PC. Instalujemy na karcie SD Raspbiana (lub inną dystrybucję) i dalej używamy tak samo jak komputer stacjonarny. Może gier jest mniej, ale minecraft działa całkiem fajnie, RetroPie pozwala na emulację starych komputerów i konsol, a użwanie kompilatora (np. gcc) nikogo nie dziwi. Raspberry Pi całkiem dobrze sobie z takimi zadaniami radzi, ale to wbrew pozorom nadal głównie komputer wbudowany. W niniejszym artykule chciałbym chociaż wprowadzić w nową opcję, czyli użycie malinki jako komputera wbudowanego - mającego jedno zadanie, które dobrze wykonuje. System operacyjny Wszyscy wiemy jak działa Raspberry Pi - na karcie SD mamy ulubioną dystrybucję, kartę umieszczamy w czytniku, podłączanie zasilanie, czekamy, chwilę jeszcze czekamy, a może jeszcze jedną chwilę... i mamy pulpit z ikonkami albo chociaż konsolę do wydawania poleceń. Programy pobieramy z sieci (repozytorium), apt jest prosty i sympatyczny w użyciu. A gdybyśmy tak spróbowali przygotować własną, mniejszą ale dopasowaną do naszych potrzeb wersję systemu? Okazuje się że nie jest to aż tak trudne (chociaż proste też nie jest), w nagrodę będziemy za to mogli pozbyć się problemów o których wspominałem na początku artykułu. Yocto Własną dystrybucję Linux-a można przygotować zupełnie od podstaw - zaczynając od kompilacji kompilatora. Jest to jednak dość złożony proces, świetny do nauki, ale niekoniecznie wygodny. Na szczęście znajdziemy gotowe projekty przygotowujące naszą dystrybucję linuksa od podstaw. Buildroot (https://buildroot.org/) jest jednym z takich projektów - pozwala on na łatwe wybranie potrzebnych nam programów oraz ich skompilowanie ze źródeł. Ostatnio coraz większą popularność zyskuje jednak inny projekt - Yocto (https://www.yoctoproject.org/). Działa o wiele wolniej niż buildroot (jak to z narzędziamy opartymi o Pythona bywa), ale lepiej sprawdza się w dużych projektach. W następnym wpisie postaram się opisać jak można użyć Yocto to przygotowania własnej wersji systemu dla malinki. Jeszcze dwa słowa odnośnie buildroot-a. Dawno, dawno temu opisywałem jak użyć go podczas instalowania linuksa na netbook-u domyślnie pracującym z Androidem: https://forbot.pl/blog/sprawdz-jak-tanio-zbudowac-robota-z-systemem-linux-id7751 To co chcę teraz opisać to bardzo podobne rozwiązanie, ale zamiast netbook-a jest Raspberry Pi, a rolę Androida zajmuje Raspbian. No i po tych kilku latach yocto uzyskało pewną przewagę na buildrootem, więc też będzie użyte. Szybki start Żeby nie zanudzić najpierw szybki i dość ogólny opis. Celem będzie utworzenie podstawowego obrazu systemu, z którego wystartuje malinka. Najpierw należy przygotować odpowiedni komputer PC oraz system operacyjny. System to oczywiście Linux - wspierane są dystrybucje Debian, Ubuntu, Fedora, OpenSUSE oraz CentOS. Prawdopodobnie użycie innej dystrybucji jest też możliwe, może jednak wymagać dodatkowych kroków. W zależności od posiadanej wersji musimy zainstalować odpowiednie pakiety oprogramowania, wszystko znajdziemy opisane tutaj: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#required-packages-for-the-host-development-system Yocto można używać w systemie Windows lub MacOS wykorzystując maszynę wirtualną. Jednak takie rozwiązanie ma znaczącą wadę - bardzo spowalnia i tak czasochłonną kompilację obrazu systemu. Nie polecam takiego rozwiązania, lepiej używać natywnego linux-a i poszukać możliwie mocnego komputera - 4 rdzenie to raczej minimum, ale yocto potrafi nawet 44 wykorzystać (tyle testowałem), więc im silniejszy komputer tym lepiej i szybciej - a maszyny wirtualne pod względem wydajności niestety nie oszałamiają. Oprócz szybkiego procesora o możliwie wielu rdzeniach, będziemy potrzebowali również sporo miejsca na dysku. Minimum to ok. 30 GB, ale nieco bardziej rozbudowana konfiguracja może potrzebować i 100GB. Oczywiście szybki dysk ma swoje zalety, więc jeśli mamy miejsce na dysku SSD, warto go użyć. Ja wykorzystuję dysk SSD podłączany przez USB. To całkiem wydajne rozwiązanie, a możliwość odłączenia dysku od stacji roboczej i podłączenia do laptopa bardzo się przydaje. Dlatego u mnie ścieżka do projektu jest nieco długa: /mnt/usbssd/raspberry/yocto W tym katalogu należy pobrać sam projekt yocto, czyli wykonać: git clone -b sumo git://git.yoctoproject.org/poky.git Potrzebne będą jeszcze dwie tzw. warstwy, czyli powiedzmy biblioteki: meta-openembedded oraz meta-raspberrypi. Pobiera się je poleceniami: git clone -b sumo git://git.yoctoproject.org/meta-raspberrypi git clone -b sumo git://git.openembedded.org/meta-openembedded Teraz w katalogu /mnt/usbssd/raspberry/yocto znajdziemy trzy podkatalogi: poky, meta-raspberrypi, meta-openembedded. Pierwszy z nich jest dla nas najważniejszy więc wchodzimy do niego, a następnie wczytujemy zmienne ze skryptu oe-init-build-env: cd poky source oe-init-build-env Na ekranie widzimy podpowiedź co zrobić dalej, jednak zanim do tego przejdziemy musimy poprawić domyślną konfigurację yocto. Plik conf/bblayers.conf zawiera listę wybranych wartstw (bibliotek). Musimy dopisać używane przez nas, dopisujemy więc: BBLAYERS ?= " \ /mnt/usbssd/raspberry/yocto/poky/meta \ /mnt/usbssd/raspberry/yocto/poky/meta-poky \ /mnt/usbssd/raspberry/yocto/poky/meta-yocto-bsp \ /mnt/usbssd/raspberry/yocto/meta-raspberrypi \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-oe \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-multimedia \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-networking \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-python \ " Kolejny krok to edycja głównego pliku konfiguracyjnego o nazwie conf/local.conf. Domyślnie zawiera on dużo komentarzy, uproszczona wersja wygląda następująco: MACHINE = "raspberrypi3-64" DL_DIR = "${TOPDIR}/downloads" DISTRO ?= "poky" PACKAGE_CLASSES ?= "package_ipk" EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" CONF_VERSION = "1" RPI_USE_U_BOOT = "1" ENABLE_UART = "1" Pierwsza linia ustala typ naszej "maszyny", czyli Raspberry Pi 3 w wersji 64-bitowej. Jeśli używamy innej wersji, musimy odpowiednio zmodyfikować ten wpis. Co ciekawe cała dystrybucja będzie wykorzystywała ustawienia zoptymalizowane dla naszgo procesora - domyślnie Raspbian jest kompilowany tak, aby programy działały na najmniejszym wspólnym mianowniku, czyli starym Raspberry 1 - używając yocto nie tylko jądro, ale i cały system zostanie skompilowany pod nasze potrzeby. Nie zadziała na starszych płytkach, ale na naszej wykorzysta jej potencjał. Kolejny ważny parametr to ustawienie RPI_USE_U_BOOT. Dzięki niemu zostanie użyty bootloader u-boot, co pozwoli na załadowanie systemu przez sieć (TFTP), podłączenie dysku sieciowego (NFS), albo nawet użycie pamięci USB. Jest to pierwszy etap pozwalający na pozbycie się usterek na które wiele osób narzeka. W tym pliku można również wymusić użycie systemu "tylko do odczytu". Jedna dodatkowa linijka i karta SD będzie działać prawie w nieskończoność - do tego wrócimy później. Na razie czas zacząć kompilację i zrobić sobie (długą) przerwę. Wydajemy polecenie: bitbake core-image-minimal Yocto pobierze z sieci źródła wszystkich programów a następnie je skompiluje. Taki proces wymaga szybkiego łącza i trwa... od 20min do 4h. Na szczęście później jest już szybciej, ale za pierwszym razem można sobie zrobić przerwę na lunch. Po zjedzeniu lunchu, albo chociaż przerwie mamy gotowy obraz naszego systemu. Wynikowe pliki znajdziemy w katalogu tmp/deploy/images/raspberrypi3-64: Tym co na początek nas zainteresuje to plik z gotowym obrazem całej karty SD, czyli core-image-minimal-raspberrypi3-64.rpi-sdimg. Warto zwrócić uwagę na wielkość obrazu - u mnie wyszło 56 MB. To nadal bardzo dużo, ale domyślny Raspbian wymaga kilku GB. Kartę SD przygotujemy poleceniem dd, u mnie urządzenie /dev/sdh odpowiada karcie, więc polecenie: sudo dd if=tmp/deploy/images/raspberrypi3-64/core-image-minimal-raspberrypi3-64.rpi-sdimg of=/dev/sdh bs=4M Pozwala na nagranie obrazu na nośnik. Teraz można umieścić kartę w czytniku Raspberry Pi i wystartować system: Uruchomienie sytemu zajmuje znacznie mniej czasu niż w przypadku domyślnego systemu. To nadal bardzo daleka od optymalnej konfiguracja, ale i tak linux jest gotowy do pracy w kilka sekund. To co otrzymaliśmy to pierwsza, minimalna wersja systemu - mała ale zoptymalizowana dla naszego sprzętu. Nie znajdziemy na niej minecrafta, ani nawet interfejsu graficznego, ale to co wybraliśmy działa szybko i wydajnie. Mając taki system jako punkt wyjścia możemy przygotować bardziej rozbudowaną wersję, wyposażoną w potrzebne nam programy i biblioteki. Warto natomiast zwrócić uwagę na nieco inny sposób pracy z systemem. Całą kompilację wykonujemy na komputerze stacjonarnym, malinka tylko wykonuje przygotowane programy. Działa więc tak jak Arduino, a nie typowy Raspbian.
  25. 7 punktów
    Zdecydowałem się przestawić swój kolejny projekt utrzymany w klimatach retro. Wszystko zaczęło się jakiś rok temu, gdy przypadkowo odkryłem, że sprzedawcy na popularnych chińskim serwisie aukcyjnym posiadają podejrzanie duże ilości podejrzanie tanich układów MOS6502. Wydało mi się to zbyt piękne, aby było prawdziwe. Z ciekawości zamówiłem kilka sztuk, płacąc za nie kilka dolarów i zapomniałem o całej sprawie, licząc na to, że pewnie otrzymam podróbki z wygrawerowanymi laserowo oznaczeniami. Jak bardzo się myliłem! Po uruchomieniu na płytce prototypowej okazały się być prawdziwymi układami MOS6502, wykonanymi w technice NMOS. Zabrałem się więc za projektowanie właściwej płytki, myśląc o stworzeniu swojego własnego komputera pracującego pod kontrolą języka BASIC. Ten projekt ciągle jest w realizacji, ale nie o nim chcę tutaj napisać. W międzyczasie bowiem w mojej głowie pojawił się jeszcze jeden pomysł. Chciałem sprawdzić jak ta rodzina procesorów sprawdza się w roli mikrokontrolera. Albo innymi słowy - byłem ciekaw co by było, gdyby Arduino powstało trzydzieści lat temu. Tym razem od brytyjskiego sprzedawcy na eBay-u zamówiłem kilka sztuk nowszych procesorów WDC65C02, wykonanych w technologii CMOS. Zastosowanie tej wersji układów nie tylko zmniejszało znacznie pobór prądu, ale także upraszczało układ, niwelując konieczność stosowania bufora szyny adresowej. Za punkt wyjścia do tego projektu posłużyła płyta procesorowa mojego ciągle powstającego komputera na MOS6502, która została poddana pewnym modyfikacjom. Przede wszystkim zmieniła się organizacja pamięci - zwiększyłem ilość EPROM-u kosztem RAM-u, dodana została także pamięć EEPROM. Organizacja pamięci wygląda następująco, zaczynając od 0x000: 8 kB pamięci RAM 8 kB przestrzeni adresowej I/O 8 kB pamięci EEPROM 8 kB układ EPROM (dodatkowa pamięć, obecnie niewykorzystywana) 32 kB EPROM (główna pamięć, przechowująca program, dane i adresy wektorów) Urządzenie pracuje z prędkością 4 MHz. Sygnał taktowania pochodzi z jednoukładowego generatora kwarcowego. Układ DS1232 odpowiada za obsługę wejścia RST (likwidacja drgań styków i obsługa power-on reset). Urządzenie posiada także port wyjściowy na 74HCT373 - można za jego pomocą migać dwiema diodami, pozostałe linie są wyprowadzone na złącze IDC-40. Dekoder adresów jest zrealizowany na układach 74HCT138 i 74HCT139. Dodatkowo kilka bramek układu 74HCT00 posłużyło do generowania sygnałów !RD i !WR, wykorzystywanych w układach kompatybilnych z magistralą intela (a więc także zastosowanych pamięciach). Wszystkie sygnały szyny danych, adresowej, te związane z obsługą przerwań oraz wyjścia dekodera adresów są wyprowadzone na złącze IDC-40. Moim zamiarem było stworzenie płytki, która nie tylko będzie mogła służyć do eksperymentów z historyczną rodziną procesorów, ale także będzie mogła posłużyć jako podstawa do budowy jakiegoś użytecznego projektu, poprzez dodanie odpowiednich modułów, na wzór shieldów Arduino - z tą różnicą, że podpinanych bezpośrednio do magistrali procesora za pomocą taśmy IDC-40. Na pierwszy ogień poszła płytka zawierająca wyświetlacz HD44780 (4x20) oraz kilka przycisków tact switch. Wyświetlacz pracuje bezpośrednio na magistrali procesora - do tego w końcu został zaprojektowany. Konieczne było tylko dodanie prostej logiki, generującej sygnały sterujące. Od strony programowej obsługa wyświetlacza w takich systemach jest nawet prostsza niż obecnie - wystarczy jedynie wpisywać odpowiednie wartości pod odpowiednie adresy w przestrzeni adresowej procesora. Przyciski posiadają własny port wejściowy, zrealizowany na 74HCT245. Praca nad tym projektem była dla mnie także okazją do zapoznania się z asemblerem 6502, chociaż prawdę mówiąc większość kodu napisałem w C posługując się kompilatorem cc65, uzupełniając go o asemblerowe wstawki. Co prawda jest to dość prosty kompilator i być może nie nadaje się do pisania gier pod Commodore C64, ale w w tego typu zastosowaniach sprawdza się całkiem nieźle.
  26. 7 punktów
    Witajcie! Bolt to robot klasy Linefollower Standard. Został zaprojektowany, zbudowany oraz zaprogramowany przez kolegę Hubert.M oraz mnie. Jest on naszą najnowszą konstrukcją. Konstrukcja mechaniczna. Robot składa się z 2 płytek PCB, wykonanych przez firmę SATLAND Prototype. Płytki połączone są dwiema węglowymi listewkami, a z tyłu robota znajduje się aluminiowa podpórka zabezpieczająca przed przewróceniem się robota. Podpórkami listwy czujników są tranzystory w obudowie TO92. Silniki użyte w robocie to popularne Pololu HP 10:1. Koła wykonał dla nas hungrydevil. Masa robota z baterią wynosi 69 gramów. Elektronika. Zdecydowaliśmy się na mikrokontroler STM32F103C8T6. Silniki sterowane są układem TB6612. Zastosowane czujniki linii to KTIR0711. Czujników na chwilę obecną jest 9. Zastosowaliśmy moduł bluetooth HC-05. Zastosowanie modułu znacznie ułatwiło strojenie robota. Ponadto stan każdego czujnika jest odzwierciedlony diodą LED. Robot zasilany jest pakietem Li-pol o pojemności 150mAh. Część logiczna robota zasilana jest napięciem 3.3V. Program. Algorytm robota jest napisany w języku C. Zastosowano regulator PD. Dzięki modułowi BT wszystkie nastawy regulatora mogą być ustawiane bez ponownego programowania robota. Ponadto, program pozwala na np. zdalne sterowanie robota po połączeniu z komputerem. Do zażądania robotem napisaliśmy 2 aplikacje – na telefony z systemem android, aplikacja pozwala na wystartowanie robota, a także na jego zatrzymanie. Z Kolei aplikacja na PC oprócz podstawowej funkcjonalności pozwala na dobieranie nastaw robota. Ponadto można za jej pomocą rysować wykresy uchybu i pochodnej z uchybu. Bolt ma brata bliźniaka, o nazwie Bez Nazwy. Jest on nieco szybszy od Bolta (bo czerwony). Osiągnięcia i plany na przyszłość. - 2 miejsce na Konkursie robotów SEP Gdańsk 2015 - 4 miejsce na SUMO Challenge 2015 W robocie planujemy jeszcze bardziej poprawić jakość sterowania, oraz rozważamy wykonanie węższej listwy czujników z czujnikiem odległości, aby móc startować w kategorii LF Enhanced. Film z przejazdu:
  27. 7 punktów
    Witam wszystkich forumowiczów. Chciałbym przedstawić moja pierwszą jeżdżącą konstrukcje. Jest to samobieżna platforma sterowana poprzez bluetooth poprzez laptopa/PC lub telefon. WSAD: Wsad do mikro-kontrolera powstawał najwięcej czasu z racji braku doświadczenia w pisaniu wsadów, wiem na pewno że da się go zrobić prościej i schludniej ale mi wystarczy zadowolenie że działa. Jest on bardzo wzorowany na sterowniku bluetooth opublikowanym w EdW 01/09 i kopią wsadu do konstrukcji bluerider opublikowanej na innym forum. Działania wsadu nie będę opisywać ponieważ jest w nim dodanych wiele komentarzy opisującym całe sekcje i za co są one odpowiedzialne. W kilku miejscach powstaje małe zamieszanie w przypisywaniu portów ale wszystko to poprzez dalsze prace nad konstrukcją ramienia z chwytakiem które zostały wstrzymane do stycznia. Gorąco polecam samo zapoznanie się z możliwościami takiego starowinka bluetooth. PROGRAM PC/KOMÓRKA: Twórca tych programów jest osoba która jest autorem całego artykułu o którym pisałem wcześniej. Jeśli jest ktoś zainteresowany programem należy na stronie: http://www.elportal.pl/index.php?module=ContentExpress&func=display&btitle=CE&mid=&ceid=93 odszukać: Do pobrania z EdW 1/2009 a następnie wybrać odnośnik do: Sterownik Bluetooth - płytka drukowana, oprogramowanie (ZIP, 2100kB) . NAPĘD: Do napędzenia robota posłużyły dwa przerobione serwa modelarskie sterowane poprzez podwójny scalony mostek typu H. Serwa bezpośrednio przekazują napęd na łańcuch pełniący role gąsienic. Myślę że nie ma co się tutaj rozpisywać, istnieje wiele rodzajów napędów i sposobów na przenoszenie go ale mi ten najbardziej pasował. ZASILANIE: Całość jest zasilana z 8 akumulatorków energizer, wybrałem takie zasilanie ponieważ miałem ich dużo i chciałem je jakoś wykorzystać. W projekcie są użyte dwa stabilizatory 7805 oraz 7808 do zasilania silników. ELEKTRONIKA: Całością steruje mikro-kontroler atmega8. Procesor znajduje się w pętli do loop, oczekując na komunikaty od BTM. Jeżeli odbierze prawidłowy znak, ustawia stan na odpowiednim porcie procesora, a następnie wysyła do modułu informację o stanie wszystkich wyjść. Do sterownika dołączone jest napięcie 5V oraz 8V. Stabilizacja odbywa się w innym module. Budowa elektroniki w systemie modułowania sekcji była wymuszona przez bardzo małą ilość miejsca w która musiałem zmieścić cała elektronikę. KOMUNIKACJA: Podzespołem odpowiedzialnym za komunikacje pomiędzy platforma a PC/komórka jest moduł bluetooth btm-222. Wzór PCB został pobrany z: http://www.elektroda.pl/rtvforum/viewtopic.php?t=1414894&highlight= natomiast dokładny opis komunikacji jak i działania samego modułu znajduje się na stronie http://www.elektroda.pl/rtvforum/topic1433390.html#7043207. Dodam jedynie że moduł wymaga napięcia 3,3V przez co zastosowany jest konwerter napięć oraz że warto jednak wybrać PCB z wbudowanymi diodami( od razu widać czy komunikacja odbywa się prawidłowo). W mojej konstrukcji zastosowany jest dokładnie moduł btm-220A nie różni się on niczym od opisywanym wcześniej btm-222, pracuje on w klasie 1( do 100m zasięgu) faktycznie testowałem na 30m i działał bez problemu dodana jest także antena od zwykłego access point'a taka zwykła za 9 zł. PCB: Zostały one wykonane przeze mnie na podstawie dokumentacji technicznych bibliotek oraz materiałów dostępnych w internecie. Płytki są jednostronne poza modułem bluetooth, PCB pobrana z sieci, jedynie przerobiona na moje potrzeby( dodane gniazdo antenowe) i można je spokojnie wykonać w domowych warunkach. KONSTRUKCJA: Całość została upchnięta w uniwersalna obudowę dodany został tez kątownik aluminiowy odpowiedzialny za wzmocnienie osi pojazdu na których znajduje się całe obciążenie. Budowa ramienia z chwytakiem ciągle w budowie. ZAŁĄCZNIK: W załączniku znajdują się wszystkie wzory PCB oraz wsad do atmegi. Do goldpinu JP1( plik RAT1) należy podłączyć sterowanie PWN lub tak jak u mnie napięcie 5V. UWAGA!!! w projekcie RAT1 znajduje się błąd elementy bc848 należy przylutować napisem do PCB. Mam nadzieje że o niczym ważnym nie zapomniałem, jest to moja pierwsza konstrukcja którą opisuje wiec tez mam nadzieje że niczym nie zdenerwowałem moderatorów i nie złamałem kilku punktów regulaminu. Na koniec film i parę zdjęć: Teraz kilka zdjęć z budowy ramienia: RAT.rar
  28. 6 punktów
    Od dawna interesowały mnie pomiary warunków meteorologicznych w mojej miejscowości, pierwsza stacja meteorologiczna, którą zbudowałem około roku 2010, wykonana była na mikrokontrolerze Atmega32. Do komunikacji z światem wykorzystywała moduł LAN Wiznet 7010a. Stacja ta była oprogramowana w języku BASCOM. Projekt który chcę zaprezentować dzisiaj działa już od roku 2018 i został oprogramowany w środowisku Arduino. Stacja została podzielona na 2 moduły, pierwszy pomiarowy oparty jest na klonie Arduino Nano oraz drugi odbiorczy którego sercem jest ESP8266 NodeMCU v3, służy on również do wyświetlania aktualnych pomiarów na wyświetlaczu LED dot matrix o wymiarach 8x56 punktów. Na pracach stolarskich się nie będziemy skupiać napiszę tylko że klatka meteorologiczna została wykonana z drewna sosnowego i umieszczona na wysokości 2 m. Moduł Pomiarowy Czujniki jakie zastosowałem to dwie sztuki DS18B20 pierwszy zajmuje się pomiarem temperatury przy gruncie na wysokości 5cm, drugi pełni rolę zapasowego czujnika temperatury na wypadek uszkodzenia się głównego czujnika BME280. Do pomiaru prędkości wiatru wykorzystuję wiatromierz firmy Maplin na jeden obrót wiatromierza przypadają 2 impulsy z kontaktronu który jest w nim zamontowany, producent dostarcza również odpowiedni wzór według którego można obliczyć rpm oraz prędkość wiatru w km/h. Dane mierzone przez wiatromierz możemy podzielić na dwie wartości, pierwsza to chwilowa prędkość, druga prędkość w porywach, aby uśrednić wartości mierzone program zlicza impulsy z 5s a następnie dokonuje odpowiednich obliczeń. Zebrane dane przesyłane są do drugiego urządzenia poprzez moduły radiowe które działają na częstotliwości 433,92 MHz. W tym celu zastosowana została biblioteka RCSwitch. Każda mierzona wartość jest wysyłana jako osobna transmisja. aby rozróżnić pomiary z konkretnych czujników mierzona wartość mnożona jest przez 100 a następnie dodawana jest liczba 100 000 dla pierwszego czujnika, 200 000 dla drugiego itd. Przykład kodu który realizuje tę funkcję poniżej: // temperatura sensor BME codetosend = temp * 100 + (1 * 100000); mySwitch.send(codetosend, 24); // wilgotnosc sensor BME codetosend = hum * 100 + (2 * 100000); mySwitch.send(codetosend, 24); Moduł Wewnętrzny Obudowa, która idealnie nadawała się do implementacji wewnętrznego modułu pochodzi z tunera IPTV Motorola VIP1910-9. Przedni panel został wykonany z ciemnego półprzepuszczalnego plastiku który idealnie nadaje się do umieszczenia w nim wyświetlacza. Sercem urządzenia jest układ ESP8266. "Moduł wewnętrzny" został również wyposażony w czujnik temperatury oraz wilgotności DHT22, dodatkowo w celu prezentacji zmierzonych wartości dołączone zostało 7 szt. modułów wyświetlacza LED dot matrix z układem MAX7219. Do obsługi tej matrycy zastosowałem bibliotekę Max72xxPanel.h która współpracuje z biblioteką Adafruit_GFX.h w ten sposób nie byłem zmuszony implementować do rozwiązania własnych czcionek. Matryca ta oprócz modułowej konstrukcji umożliwia również sterowaniem jasnością podświetlania, w tym celu aby uprzyjemnić użytkowanie w porach nocnych odbiornik został wyposażony w fotorezystor dzięki któremu potrafi określić natężenie oświetlenia otoczenia i odpowiednie ustawienie podświetlenia. Na wyświetlaczu w pierwszej kolejności wyświetlam aktualną godzinę oraz temperaturę wewnątrz pomieszczenia oraz wilgotność, po około jednej minucie wyświetlane są informacje odczytane z stacji meteo czyli temperatura wilgotność i ciśnienie, postanowiłem nie wyświetlać tutaj informacji dotyczących prędkości wiatru oraz temperatury przy gruncie. Decyzję tą podjąłem na podstawie użytkowania innego podobnego rozwiązania, akurat jak chcemy odczytać godzinę to wyświetlane są inne informacje. Dodatkowo w godzinach nocnych, które zostały ustawione w sztywnych ramach czasowych między 21:00 a 7:00 informacje odczytane z stacji meteo zostały okrojone tylko do temperatury. W projekcie zostały zastosowane 2 rodzaje animacji pierwsza z nich, przesuwa tekst z prawej strony wyświetlacza na lewą, z możliwością zatrzymania w interesujących momentach. Drugi rodzaj to pionowa animacja. Mikrokontroler również poprzez protokół NTP i bibliotekę time.h pobiera aktualną godzinę i datę. Za odbiór danych z pierwszego układu odpowiedzialny jest moduł radiowy którego obsługą tak jak w poprzednim module zajmuje się biblioteka RCswitch. Poniżej fragment programu który demonstruje w jaki sposób odbierane i dekodowane są dane: rc = mySwitch.getReceivedValue(); // czujnik temperatury powietrza BME280 if (abs(rc)>=50000&& abs(rc)<150000) { rc=(rc-100000)/100; if (rc > -50 and rc < 60) { temp1 = rc; Serial.print("Czujnik BME280 - temperatura: \t"); Serial.println(rc); matrix.drawPixel(55,0,1); matrix.write(); } } // czujnik wilgotności BME280 if (abs(rc)>=150000 && abs(rc)<250000) { rc=(rc-200000)/100; if (rc > 5 and rc <= 100) { hum = rc; Serial.print("Czujnik BME280 - wilgotnowsc: \t"); Serial.println(rc); matrix.drawPixel(55,1,1); matrix.write(); } } Dzięki zastosowaniu zewnętrznej anteny oraz odbiornika opartego na superheterodynie, zasięg w otwartym terenie to około 250 m. Po odebraniu danych z pierwszego układu poprzez moduł radiowy następuje przekazanie ich do serwera z systemem Domoticz. Domoticz to bardzo lekki system automatyki domowej, który pozwala monitorować i konfigurować różne urządzenia, przełączniki, czujniki takie jak temperatura, opady deszczu, wiatr, promieniowanie ultrafioletowe (UV), zużycie energii elektrycznej, zużycie gazu, zużycie wody i wiele więcej. Wykresy dostępne są również na stronie www http://meteo.palowice.net Poniżej film z działania odbiornika, smużenie animacji które występuje na filmiku ludzie oko nie rejestruje. Gdyby kogoś interesował kod to również zamieszczam: meteo.zip
  29. 6 punktów
    Jakiś czas temu na portalu z ogłoszeniami natknąłem się na ofertę sprzedaży zabytkowego układu scalonego AY-3-8500. Jest to dość specyficzny element, wykorzystywany na przełomie lat siedemdziesiątych i osiemdziesiątych do budowy konsol do gier pierwszej generacji. Układ scalony zawiera w swojej strukturze kompletną logikę, niezbędną do generowania kilku prostych gier, m.in. kultowego "Ponga". Wykorzystywany był m.in. w kultowym ELWRO/Ameprod TVG-10 - jedynej polskiej konsoli do gier, jaka trafiła do masowej sprzedaży. Oczywiście nie byłbym sobą, gdybym go wtedy nie kupił i nie spróbował odpalić. Zacząłem więc szukać w Sieci informacji na temat tego układu. Efekty tych poszukiwań przeszły moje oczekiwania - natknąłem się na stronę, której autor zajął się podobnym projektem. Była tam cała niezbędna dokumentacja, karty katalogowe, a także projekt płytki drukowanej konsoli wykorzystującej posiadany przeze mnie układ scalony. No cóż... Postanowiłem nie wyważać otwartych drzwi i wykorzystałem ten wzór, prowadzając jednakże pewne modyfikacje w swojej implementacji tego projektu. Największa z nich dotyczyła kontrolerów , które zbudowałem w oparciu o niewielkie, plastikowe obudowy. Musze przyznać, że tworzą one całkiem poręczne "pady". Każdy z kontrolerów jest wyposażony w potencjometr służący do kontrolowania położenia paletki oraz przycisk do serwowania. Sama konsola została umieszczona w typowej plastikowej skrzynce. Na przednim panelu znajdują się przełączniki dźwigniowe dwu i trzypozycyjne służące do konfiguracji trybu rozgrywki, a także przełącznik obrotowy, do wyboru właściwej gry. Układ AY-3-8500 pozwala na korzystanie z pistoletu świetlnego. Dwie z generowanych przez niego gier wymagają posiadania takiego sterownika. Zdecydowałem się jednak zrezygnować z jego budowy. Na płytce są wyprowadzone odpowiednie piny, więc w przyszłości będzie możliwa taka rozbudowa. Niestety strona na której znalazłem oryginalny projekt niedługo później przestała działać, jednak wciąż można się do niej dostać przez Wayback Machine. Konsola przez jakiś czas była dostępna na wystawie "Game start/game over" w krakowskim Muzeum Inżynierii Miejskiej. Przetrwała - grupy gimnazjalistów nie były w stanie jej zniszczyć. W ramach ciekawostki mogę dodać, że mojemu sześcioletniemu siostrzeńcowi spodobała się ta gra sprzed kilku dekad.
  30. 6 punktów
    Witam. W kilku kolejnych częściach kursu chciałbym przedstawić proces tworzenia własnej aplikacji na telefon, tablet lub inne urządzenie z system Android. Aplikacja będzie miała za zadanie sterować naszym robotem, lub dowolną inną konstrukcją, oraz będzie mogła przedstawiać aktualny stan, oraz wybrane parametry / odczyty urządzenia. Wszystko to za pomocą łączności bezprzewodowej, niewielkim kosztem i za pomocą stosunkowo szybko zrobionej własnej aplikacji na popularne ostatnimi czasy urządzenia z system od google’a. [blog]https://forbot.pl/blog/artykuly/programowanie/tworzenie-aplikacji-android-1-wstep-id4486[/blog]
  31. 6 punktów
    Chociaż program Eagle firmy CadSoft posiada preinstalowaną, bardzo bogatą bibliotekę elementów, a dodatkowo w internecie można znaleźć "gotowca" do większości części, pojawia się czasami konieczność zaprojektowania własnej obudowy lub nawet wykonania biblioteki elementu od zera. Obiecaną trzecią część kursu chciałbym poświęcić właśnie tworzeniu biblioteki od zera. Przed rozpoczęciem prac warto zajrzeć do poprzednich części, jest tam szczegółowo omówiona większość podstawowych funkcji Eagle. Dodatkowo zachęcam do eksperymentowania w trakcie wykonywania kolejnych kroków - w razie problemów zawsze można cofnąć kilka ostatnich kroków (Ctrl + Z). Jako przykład wybrałem zyskujący coraz większą popularność w robotyce transoptor odbiciowy (czujnik linii) KTIR0711S. [blog]https://forbot.pl/blog/cadsoft-eagle-czesc-3-tworzenie-biblioteki-id1605[/blog]
  32. 6 punktów
    Witam serdecznie, konstrukcja którą stworzyłem jest pierwszym doświadczeniem tego typu, ponieważ bardzo interesują mnie roboty mobilne którymi można sterować ze znacznej odległości i wykonywać różnego rodzaje prace, tym bardziej fascynuje mnie to iż najprawdopodobniej tak będzie wyglądała nasza przyszłość gdzie większość czynności będą wykonywały zdalnie sterowane roboty, a także te ze sztuczną inteligencją. Dlatego też postanowiłem stworzyć niewielkim kosztem pojazd który będzie w stanie coś podnieść, przenieść, sfilmować z niewielkiej odległości. Długi czas myślałem nad rozwiązaniem jakie zastosować podwozie, idealne wydawało mi się podwozie gąsienicowe Tamiya, lecz było zbyt małe, dlatego też zastosowałem podwozie z koparki które dodatkowo posiada możliwość obrotu kabiną, niepotrzebną górę i cały korpus zdemontowałem i delikatnie przebudowałem aby powstała możliwość zainstalowania ramy nośnej wszystkich elementów, powstała tzw nadbudówka z wykorzystaniem plastikowych obudów w której znalazły się wszystkie elementy elektroniczne - ma to też taką korzyść że nie są narażone na czynniki zewnętrzne. Przystępując do pracy mając odpowiednie elementy takie jak serwa modelarskie, części mechaniczne, oraz chwytak zmontowałem ramię: Następnie konstrukcja zaczynała przypominać to co w chwili obecnej: lecz pojawiły się pierwsze problemy z jakimi musiałem walczyć, mianowicie było to mocowanie ramienia do ramy głównej i przeniesienie odpowiedniej siły, by nie opadało automatycznie pod własnym ciężarem, do tego też serwo chwytaka i obrotnika to Futaba o momencie 3,2kg, natomiast dwa kolejne są z metalowymi zębatkami Tower Pro 996R o momencie 12kg, a zastosowanie odpowiedniego przeniesienia mocy poskutkowało znakomicie co widać na zdjęciach: ramię nie opada samoczynnie, choć trochę waży. Kolejne etapy to planowanie rozłożenia poszczególnych elementów tak by całość nie przypominała stosu kabli. wtedy także pojawił się kolejny problem jakim było zasilanie wszystkich elementów, obecnie zostałem przy koszyku 6xAA choć to stanowczo za mało, niebawem spróbuję kupić koszyk na minimum 8sztuk lub pakiet około 11V, ponieważ jest trochę "odbiorników prądu" pod względem elektronicznym są to kolejno idąc od zasilania: 1.przetwornica oraz stabilizator napięcia z wyświetlaczem LED 2. Miniaturowa przetwornica napięcia 5V 800mAh - dla zasilania wentylatorka 3.Programator USB komunikacyjny z Arduino Mini Pro 4. Wyświetlacz LED mierzący napięcie wyjściowe drugiego obwodu zasilającego takie elementy jak oświetlenie LED oraz Arduino 5. Dodatkowa przetwornica napięcia 5V 800mAh dedykowana dla Arduino 6. Główny moduł Arduino Mini Pro ATmega328 z zegarem 16Mhz 7. Sterownik serwomechanizmów Mini Maestro Polulu 6-kanałowy 8. Sterownik bipolarnego silnika krokowego w wyposażeniu lecz aktualnie brak zastosowania Elektronika została podłączona w ten sposób by całość mogła być sterowana z poziomu Arduino, czyli sterownik serwomechanizmów Mini Maestro ma dwie możliwości kontroli nad serwami: pierwsza to bezpośrednio kablem USB, a druga to sterowanie przez moduł Arduino i tak np zapisanie na nim odpowiednich komend i ich późniejsze odtwarzanie, całość została zmontowana tak że można go wyposażyć o np czujniki odległości SHARP'a i napisać odpowiednie sekwencje ruchów, przekaźnik nie pełni tu istotnej roli w danej chwili gdyż odpowiada tylko za migotanie niebieskiej diody, pod moduł Arduino podłączony jest zestaw diod LED które migotają na pomarańczowo oraz czerwono, a także sterownik bipolarnego silnika krokowego którym można łatwo sterować, ale póki co nie znalazłem dla niego zastosowania. Po zmontowaniu całości i wyposażeniu w kamerkę oraz zastosowaniu w niej czerwonej migającej diody prezentuje się świetnie zwłaszcza w tak pomalowanym "bojowym" kolorze militarnym
  33. 6 punktów
    Wielce nieprawdopodobnym jest, by ktoś związany z branżą elektroniczną, robotyczną lub informatyczną nie słyszał o „superkomputerze Raspberry Pi” i wcale nie jest to coś zadziwiającego, ponieważ na długo przed fazą produkcji zaczęły zawiązywać się malinowe fankluby i społeczności wyznające malinową religię. [blog]https://forbot.pl/blog/raspberry-pi-w-robotyce-amatorskiej-1-wprowadzenie-id1254[/blog]
  34. 6 punktów
    Witam chciałbym wam przedstawić mojego pierwszego robota o nazwie MacLiner.Cała konstrukcja oparta na laminacie 3mm, która jest jednocześnie płytką drukowaną elektroniki. Robot jest w kształcie Koła. MECHANIKA Tradycyjnie jak prawie w każdym robocie tej klasy zastosowane zostały dwa silniki Pololu 30:1, ball caster który stanowi tylną podporę a także koła o średnicy 32mm tej samej firmy. ELEKTRONIKA Jako "mózg" został użyty mikrokontroler firmy Atmel z rodziny AVR ATmega32 z taktowaniem 16Mhz. Za sterowanie silnikami odpowiedzialny jest dwukanałowy mostek L298. Z początku obawiałem się użycia go ze względu na duży spadek napięcia, lecz jak się potem okazało w tej konstrukcji w zupełności wystarczał.Do wykrywania linii użyte zostały czujniki KTIR0711S (5 czujników ułożonych po okręgu ). Sygnał analogowy z sensorów zamieniany jest na cyfrowy przy użyciu komparatorów LM324 następnie podawany na piny atmegi. Za stabilizacje napięcia odpowiedzialny jest układ 7805, który dostawał napięcie w prost z 4 baterii alkalicznych 1,5v.Płytka została wykonana w warunkach domowych. Od razu odpowiem na pytanie(zapewne takie padnie). Z czego zrobiona jest soldermaska? Otóż jest to najzwyklejsza farba do witraży. STEROWANIE Myślę, że największą wadą tego robota jest właśnie program. Można było zauważyć to na zawodach SUMO CHALLENGE w Łodzi (zakręty pokonywał w moim odczuciu doskonale, lecz na prostych wyglądało to jak by jechał po sinusoidzie). Został wgrany regulator na samym członie P pisany w środowisku Bascom. PODSUMOWANIE Reasumując zebrałem dużo cennego doświadczenia, na pewno więcej czasu muszę poświęcić na napisaniu programu a także to że softem ciężko jest naprawić błędy mechaniczne/konstrukcyjne. Zapomniał bym o jeszcze jednej cennej praktyce, którą zdobyłem podczas budowy: zarywanie nocek przy projekcie dobrze się nie kończy co widać na jednym ze zdjęć(mam na myśli te źle rozmieszczone pady pod diody) Zdjęcia: MACLINER TEST [Youtube] [/Youtube][Youtube] [/Youtube]Autor projektu: *Mateusz Góra MacLiner.pdf
  35. 6 punktów
    Witam chciał bym przedstawić mojego pierwszego robota minisumo szamana 4 Robot ten powstał z myślą o zawodach, ale jak na razie jest w fezie testów.Robiłem go 3 dni ale pomysł powstał 1 miesiąc wcześniej. Elektronika. Robot jest sterowany atmegą8, wybrałem ją z powodu jej posiadania w domu. Czujniki to 2x GP2Y0D340K i 1x tcrt1000 podpięty do wzmacniacza operacyjnego i zainstalowanego z przodu.Zrezygnowałem z 4 czujników ponieważ sam jeden spełnia swoje zadanie.sterownikiem napędu jest mostek 293dne. Program. Program jest w całości napisany w języku bascom,na płycie głównej robota znajduje się złącze programistyczne(ISP). Napęd. Jako napędu użyłem przekładnię tamitya i koła z pololu jednakże, ogumienie nie spełniało moich oczekiwań zastosowałem własne gumy z drukarki . Zasilanie. Zasilanie stanowią 4 akumulatorki NI-MH 2500mAh firmy tronic.Całość jest stabilizowana stabilizatorem 5v Zrezygnowałem z robienia płytek bo nie lubię bawić się w wytrawianie. Na ich miejsce weszły płytki uniwersalne co okazało się głupim pomysłem . filmik z pracy oto kilka zdjęć autor Bartłomiej Zuba (zuba1)
  36. 6 punktów
    Witam kolegów. Postanowiłem zaprezentować projekt ultradźwiękowego czujnika odległości. Pomysł zaczerpnąłem z tutoriala p. Teodora Otulaka. I postanowiłem go jakoś poprawić. W skrócie o co chodzi: Przedstawiony czujnik odległości zrealizowany jest za pomocą przetworników ultradźwiękowych. Przetworniki te są łatwo dostępne ich koszt to ok. 8-10zł za komplet (nadajnik plus odbiornik). Mózgiem jest ATmega8. Odległość jest wyświetlana na dwóch wyświetlaczach 7segmentowych oraz dodatkowo za pomocą czterech pinów portu C. Całość nie doczekała się jeszcze niestety płytki PCB ze względu na brak czasu. Całość została zmontowana na nieocenionej płytce stykowej. CZĘŚĆ ELEKTRONICZNA: Wyświetlacze 7 segmentowe są podłączone do PORTB przez rezystory 500Om. W celu zmniejszenia poboru prądu można użyć nawet 1k. Segmenty zostały podłączone do portu B w następujący sposób: Led A - PB2; Led B - PB1; Led C - PB7; Led D - PB0; Led E - PB5; Led F - PB3; Led G - PB4; Led H - PB6; Oznaczenia segmentów: Oto schemat: Jeśli nie chcemy to możemy nie montować w ogóle wyświetlaczy. Katody wyświetlaczy zostały podłączone bezpośrednio do pinów PC0,PC1. Przetworniki ultradźwiękowe podłączyłem sposób następujący: nadajnik (oznaczony literą T) do PD0 i PD1, a odbiornik ® do komparatora analogowego AIN0 (PD6) i AIN1 (PD7). Do nóżek odbiornika podłączyłem rezystor w celu eliminacji zakłóceń. Ważne jest też, żeby nadajnik i odbiornik były czymś oddzielone (u mnie jest to aluminiowy radiator). Można też nieco rozchylić przetworniki. Również możemy je umieścić w metalowych krótkich rurkach wystających kilka mm ponad przetworniki. Robimy tak ponieważ dźwięki z nadajnika od razu może słyszeć odbiornik, w związku z czym odbiera nie dźwięki odbite ale te bezpośrednio z nadajnika. U mnie działo się tak cały czas więc oddzieliłem je radiatorem. Lepszym jednak rozwiązaniem byłyby rurki bo w moim przypadku odbiornik odbierał dźwięki nawet wtedy kiedy coś było obok niego a nie bezpośrednio naprzeciwko. Zauważyłem też, że nie wszystkie przetworniki ultradźwiękowe są takie same (to chyba normalne;). Podczas testowania używałem dwóch kompletów z zupełnie innych źródeł. Różnice polegały na tym że wyświetlały troszkę inne odległości aż o około 2cm. Inne mogą pokazywać jeszcze inaczej, dlatego jeśli chcemy mieć dokładnie tyle ile się wyświetla można zmienić troszkę program. Układ pobiera w czasie pracy maks 35mA. CZĘŚĆ PROGRAMOWA: Program napisany został w języku C. Odbiór ultradźwięków postanowiłem zrobić to za pomocą przerwania zewnętrznego. Po zmianie programu i testach stwierdziłem że to nie najlepszy pomysł. Często pojawiały się zakłócenia i układ wariował. Zmniejszył się też zasięg i układ się powiększył o kilka elementów. Poza tym obsługę wyświetlaczy zrobiłem na przerwaniach od timera0 i troszkę mi to kolidowało. Dałoby się to rozwiązać ale... Skorzystałem z komparatora analogowego. Po kolejnych testach zmieniłem rezystor przy odbiorniku zamiast 220k dałem 100k. Dobrałem go eksperymentalnie. Za małe wartości zmniejszały zasięg, a za duże nie eliminowały wszystkich zakłóceń. Wcześniej np. przy odległości ok. 20-30cm układ czasami wariował i wyświetlał na chwilkę odległość ok. 5cm. Przy oporze 100k już się nic takiego nie działo. Kolejnym pomysłem było dodanie jakiegoś innego sposobu informowania o zmierzonej odległości. Wyświetlacz wygodny pomysł jak chcemy mieć prosty sposób na odczyt odległości-ot taki bajer. Ale jeśli będziemy chcieli zastosować czujnik np przy robocie to beznadzieja. Pomyślałem więc że dorobię jeszcze jedną sygnalizacje odległości. I zrobiłem tak: Wraz ze zmniejszaniem się odległości od przeszkody, na niewykorzystanych pinach portu D kolejno pojawia się stan wysoki. Tj: 15-10cm -pin PD5 stan wysoki 10-5cm - pin PD4 stan wysoki 5-3cm - pin PD3 stan wysoki <3cm - pin PD2 stan wysoki Jeśli chodzi o dokładność to w dużym stopniu zależy od przetworników ultradźwiękowych i ich ułożenia. Dlatego wyświetlacz wyświetla odległości w następujący sposób: >30cm - wyświetlacz wyłączony 30-21cm - wyświetla 30; 20-16cm - wyświetla 20; 15-10cm - wyświetla 15; 10-6cm - wyświetla 10; 5-4cm - wyświetla 5; 3-0cm - wyświetla 3; Można też dopasować program do własnych przetworników zmieniając watości w tabeli zoom. Jeszcze na temat programu. Nie jest może idealny ani zabójczo przejrzysty ale miałem drobne problemy z tablicami. WinAVRa dopiero się uczę a składnia języka C w nim różni się nieco od innych kompilatorów także wybaczcie. Można go napisać trochę prościej. Ponad to jest to wersja druga programu. Pierwsza została bezpowrotnie utracona. Ta wersja zajmuje troszkę więcej pamięci w procesorze ale i tak zajmuje go niewiele. Jest też wada tego sonaru. Jeśli przedmiot jest umieszczony prostopadle to wykrywa go bez problemów. Nawet monetę 2zł wykrywa z odległości 30cm. Ale jeśli jest pod kątem 45° to już jest gorzej. Ale w przypadku odległości poniżej 10cm przedmiot i tak zostaje wykryty. To by było na tyle. Jeśli ktoś ma jakieś uwagi czy pomysły jak to poprawić lub zrobić inaczej to piszcie. Postaram się poprawić. Przepraszam za marną jakość zdjęć. Nie posiadam aparatu więc robiłem telefonem;) Sonar 3.rar
  37. 5 punktów
    LiPol Charger v1.0 / v2.0 Szanowni czytelnicy forum w tym krótkim artykule przedstawię Wam projekt ładowarki do akumulatorów litowo-polimerowych 2 celowych (7,4V). Prace nad projektem rozpoczęły się bardzo dawno temu, co można było śledzić w tym wątku. Dużą rolę w trakcie projektowania samego układu odegrał kolega @marek1707. Tak naprawdę ostateczna forma pierwszej wersji ładowarki została bardzo mocno zasugerowana przez niego dzięki temu działa ona niezawodnie. Układy zostały zaprojektowane wedle następujących założeń: możliwość ładowania akumulatorów 2 celowych przy pomocy źródła zasilania o napięciu 5V i natężeniu prądu nie większym niż 1A (na tyle pozwalały zastosowane elementy elektroniczne) oraz ładowanie z wykorzystaniem 2 paneli słonecznych 6V/300mA, które aktualnie miałem pod ręką - stąd zastosowano układ przetwornicy typu boost, zastosowanie przewodowej lub bezprzewodowej komunikacji z komputerem PC, wykorzystanie diod LED do sygnalizacji stanów pracy ładowarki, (v2.0) wyświetlanie informacji na wyświetlaczu alfanumerycznym 2x16, (v2.0) dodanie przycisków do ręcznej interakcji użytkownika z urządzeniem, (v2.0) wbudowanie prototypu prostego balansera ogniw, (v2.0) wyprowadzenie padów do programowej kalibracji przetwornika ADC. LiPol charger v1.0 Wersja pierwsza ładowarki jest wersją niekombinowaną oraz dość niezawodną. Pełny cykl ładowania akumulatora obejmuje zarówno fazę CC (stałoprądową) oraz CV (stałonapięciową). Cykl ten świetnie obrazuje WYKRES, który podrzucił mi kolega @marek1707 i który zapamiętam do końca swojego życia Zasadę działania przetwornicy boost wydaje mi się, że każdy elektronik powinien znać. Jeśli jednak czytelniku nie miałeś okazji zapoznać się z tym rodzajem przetwornic podsyłam ciekawe artykuły na ten temat: LINK, LINK. W skrócie - na wejściu przetwornica otrzymuje napięcie maksymalne 6V oraz prąd maksymalny 1A. Sygnał PWM generowany przez mikrokontroler ze stałą częstotliwością, a zmiennym wypełnieniem otwiera lub zamyka tranzystor kluczujący przetwornicę, który dzięki temu reguluje napięcie lub prąd wyjściowy przetwornicy w zależności od fazy algorytmu ładowania CC/CV. Zastosowano w tym celu najzwyklejszy regulator proporcjonalny. Mikrokontroler ma możliwość pomiaru potrzebnych parametrów tj. napięcia i prądy wejściowe/wyjściowe oraz napięcie międzyogniwowe. Napięcia są mierzone poprzez dzielniki napięciowe natomiast pomiar prądów odbywa się z wykorzystaniem układów bocznikowych. Komunikacja z komputerem odbywa się poprzez moduł Bluetooth (BTM222 lub HC-05) lub z wykorzystaniem przejściówki USB-UART. Dodatkowo domowymi metodami wykonałem shield umożliwiający podłączenie wyświetlacza alfanumerycznego 2x16. Ostatecznie wykorzystując źródło napięcia stałego 5V/1A udało się uzyskać przetwornicę o sprawności ok. 65%. Całkiem niezły wynik jak na prototyp. Straty mocy są związane ze stratami na diodzie, indukcyjności oraz NIE zastosowaniu kondensatorów typu Low ESR. Wszystkie te parametry można jeszcze trochę poprawić przez co możliwe jest zwiększenie sprawności samej przetwornicy. Wykorzystanie do ładowania paneli słonecznych zmusiło do zastosowania najprostszego algorytmu MPPT - śledzenia punktu maksymalnej mocy. Panele słoneczne połączone są równolegle przez co uzyskano większy prąd wejściowy na przetwornicę. W tym połączeniu maksymalny prąd wejściowy wynosi 600 mA dla posiadanych przeze mnie paneli 6V/300mA. Biorąc pod uwagę to, że w polskich warunkach z tych paneli jestem w stanie wyciągnąć maksymalnie 70-80% całkowitej sprawności przy bezchmurnej pogodzie prąd ładowania akumulatorów jest niewielki. Dlatego ten tryb ładowania sprawdza się raczej przy niewielkich akumulatorach. Ale najważniejsze, że się sprawdza LiPol charger v2.0 Druga wersja ładowarki nie została jeszcze przetestowana!!! Natomiast wzbogaciłem ją o kilka praktycznych dodatków, których brakowało mi w poprzedniej wersji. Wersja v2.0 została wzbogacona o prototyp balansera złożonego z dwóch oporników dużej mocy oraz tranzystorów sterowanych z poziomu mikrokontrolera, który na podstawie pomiaru napięcia międzyogniwowego decyduje o tym, który obwód „strat mocy” załączyć. Jeśli któryś z tranzystorów zostaje otwarty, przez rezystor przepływa prąd, natomiast ładowanie danego ogniwa akumulatora jest pomijane. Dzięki temu możliwe jest wyrównanie poziomów napięć na obu ogniwach. Dodatkowo wyprowadzone zostały pady pomiarowe, które znacznie ułatwiają kalibrację odczytów z przetwornika ADC. Wbudowano również konwerter USB-UART na podstawie chipu FT230XQ, wyprowadzono również piny Rx i Tx w celu podłączenia np. modułu Bluetooth. W tym projekcie udało się znacząco zmniejszyć wymiary ładowarki. Kompletne schematy obu wersji ładowarki udostępniam w pdf’ach poniżej. LiPolCharger_v1_0.pdf LiPolCharger_v2_0.pdf Wykaz ważniejszych elementów wykorzystanych w układach ładowarek: mikrokontroler ATmega32 tranzystor kluczujący MOSFET-N STS12NF30L driver MOSFET MCP1402T cewka 220 uH wzmacniacze operacyjne LM358 wyświetlacz alfanumeryczny 2x16 konwerter USB-UART FT230XQ, tranzystory bipolarne NPN i PNP dowolne, pod warunkiem, że maksymalny prąd kolektor-emiter będzie większy niż 1A. Jeśli ktoś z czytelników będzie zainteresowany tematem owych ładowarek serdecznie zapraszam do zadawania pytań w komentarzach, a także ewentualnego krytykowania (oczywiście konstruktywnego) mojego projektu.
  38. 5 punktów
    Pojawiła się potrzeba wykonania prostego sterownika do bramy garażowej, który miałby powiadamiać mieszkańców czy aktualnie garaż jest zamknięty czy otwarty oraz w dowolnej chwili sprawdzić status. Tak powstało niewielkie urządzenie montowane na szynę DIN. Jest zasilane z dowolnej ładowarki od telefonu, posiada zabezpieczenie przed odwrotną polaryzacja zasilania. Sterownik ma kilka wejść/wyjść; IN1 - dolna krańcówka od zamknięcia garażu. IN2 - górna krańcówka od pełnego otwarcia garażu. wyjście przekaźnikowe NO do zdalnego otwierania/zamykania bramy. RS485 - pozwala podłączyć czujnik odległości wykrywający czy auto jest w garażu. czujnik temperatury DS18B20. przycisk do resetowania ustawień WiFi i uruchomienia ponownej konfiguracji. W sterowniku zastosowałem popularny układ ESP8266 w wersji WemosD1 mini. Jak widać za wiele rzeczy tu nie ma, oprócz ESP znajduje się przekaźnik, DS18B20 oraz transceiver RS485. Projekt miał być prosty, szybki i jednostkowy dlatego nie zastosowałem dodatkowych stopni ochrony wejść w postaci np. optoizolacji. Tradycyjnie płytka powstała na żelazku i wytrawiona w kwasie. Polutowana i zabezpieczona lakierem do PCB. Schemat ideowy: Wspomniany wcześniej czujnik odległości jest zbudowany z wykorzystaniem ultradźwiękowego czujnika HC-SR04 i Arduino Nano, które cyklicznie wysyła informacje do głównego sterownika. Schemat czujnika: Sterownik ma zaimplementowany serwer WWW co pozwala na sterowanie praktycznie dowolnym urządzeniem z przeglądarką. A panel sterowania prezentuje się tak: Dodałem obsługę powiadomień push na telefon z wykorzystaniem mechanizmu IFTTT (if this then that). Wystarczy zainstalować tą aplikacje na telefonie, a w sterowniku wprowadzić unikalny klucz aplikacji powiązany z konkretnym telefonem. Aktualizacja oprogramowanie wykorzystuje mechanizm OTA i sprowadza się do wgrania pliku przez panel www. Dodatkowo wystawione jest proste API, które pozwala na integracje z większością systemów smart home typu Domoticz, Home Assistant itp.
  39. 5 punktów
    Cześć, Jestem z Koła Naukowego Robotyków z Politechniki Warszawskiej. Niedawno stwierdziliśmy, że w sumie fajnie by było opisać gdzieś nasze konstrukcje. Jako, że zdarza nam się korzystać z zasilaczy z czarnej listy, padło na forbota . Na pierwszy ogień chcieliśmy wypuścić jedną ze starszych maszyn – Minotaura. Jego historia była dość ciekawa – na 3 tygodnie przed ubiegłorocznymi zawodami Robomaticon razem z kolegą stwierdziliśmy, że może fajnie byłoby wystawić tam jakiegoś Micromouse’a. Postawiliśmy zatem na jak najprostsze rozwiązania, które z jednej strony pozwoliłyby nam przetestować różne algorytmy jazdy, z drugiej zaś zaoszczędziłyby czasu na wykonanie oraz programowanie. Dzięki temu jednak konstrukcja jest dość prosta i może być dobrym projektem dla początkujących robotyków. Mechanika Bazę montażową dla całego robota stanowi obudowa wydrukowana na drukarce 3D. Pierwsza wersja zakładała, że podstawa robota będzie rozpostarta na kwadracie o długości 110 mm o zaokrąglonych narożach. Po wykonaniu prototypu oraz pierwszych testach bardzo szybko okazało się jednak, że robot jest zdecydowanie za duży. Z uwagi na to, że możliwe okazało się zmniejszenie odległości pomiędzy silnikami bez uszczerbku na działaniu enkoderów magnetycznych, zdecydowano się znacznie ograniczyć wymiary robota. Kolejna (ostateczna) wersja robota miała już w podstawie kwadrat o boku 80 mm. Aby móc ograniczyć wymiary, zdecydowano się na węższe ścianki boczne. Z uwagi na dużą łamliwość, zrezygnowano z drukowanych mocowań do płytek z elektroniką i zastąpiono je gotowymi, plastikowymi dystansami. Ostateczny wynik można oglądać na zdjęciu poniżej: W robocie Minotaur zdecydowano się na zastosowanie silników POLOLU z metalową mikroprzekładnią 50:1 z obustronnym wałem. Pozwoliło to na zastosowanie enkoderów magnetycznych tej samej firmy. Na wałach silników zamocowano wykonane metodą druku 3D koła. W pierwszej wersji zastosowano opony odlewane z silikonu, jednak później (ze względu na dość szybkie zużywanie się silikonowych) zdecydowano się na wykorzystanie opon Kyosho Mini-Z. Pozwoliło to zminimalizować poślizgi. Dodatkowymi elementami są elementy podporowe, oklejone taśmą teflonową oraz górna pokrywa robota, do której jest mocowana bateria. Elektronika Ze względu na małe zasoby czasowe oraz dostępność części w laboratorium elektronika robota Minotaur została oparta na Arduino Uno. Prawie cała pozostała elektronika (z wyjątkiem sensorów) została umiejscowiona na shieldzie wpinanym w Arduino. Poza wspomnianymi wcześniej silnikami z enkoderami, zastosowano jedynie kilka komponentów. mostki TB6612FNG, które (ze względu na przykre doświadczenia w poprzednich konstrukcjach) zastosowano po jednym dla każdego silnika (zwarto wyprowadzenia). Za interfejs użytkownika służyły 1 przycisk oraz 1 dioda. Poza tym za pomocą dzielnika napięcia monitorowano stan baterii. Aby poprawić jazdę, zdecydowano się na zastosowanie czujnika IMU (Pololu Mini-IMU 9), który znaleźliśmy w laboratorium. Jednak, nawet przy wyłączonym żyroskopie robot radził sobie w labiryncie. Wypinany moduł Bluetooth służył głównie do doboru nastaw podczas programowania (obecnie nie jest on wykorzystywany). W robotach zastosowano czujniki odległości stworzone z 2 diód IR oraz fototranzystora. Światło emitowane przez diodę IR odbija się od ściany labiryntu i wraca do fototranzystora. Zastosowano jedynie 3 takie czujniki, umiejscowione na środku ścian robota. Jeden z nich ma za zadanie sprawdzać, czy ściana jest na wprost. Pozostałe 2 umiejscowione na bokach sprawdzają, czy ścianka istnieje z boku. Pozwalają także robotowi utrzymać stałą odległość pomiędzy ściankami. Innym ich wykorzystaniem jest snapowanie – jeżeli robot ma mały błąd kątowy (liczony na bieżąco), to w momencie gdy jakaś ścianka mu się kończy, aktualizuje swoje położenie. Algorytm Podobnie jak w większości konstrukcji, które nie poruszają się metodą prawej/lewej dłoni, w robocie został zaimplementowany algorytm „flood fill” - zalewania wodą (Bellmana - Forda). Naszą jedyną modyfikacją, była preferencja jazdy prosto (obrót jest dla nas bardziej kosztowny). Aby nie zmuszać bardziej zaawansowanych czytelników do przewijania, początkujących odsyłam do linku: [LINK] Aby móc choć nieco przystosować się do warunków zmiennego oświetlenia, na początku każdego przejazdu dokonujemy kalibracji. Aby robot mógł swobodnie poruszać się po labiryncie powinien on potrafić wykonywać 2 podstawowe ruchy: jazda do przodu oraz skręt (o 90o w prawo i lewo, obrót o 180o). Przed jazdą powinien on jednak skalibrować czujniki. Do obrotu wykorzystywane są dwa czujniki: enkodery oraz żyroskop. Wiodącym czujnikiem jest żyroskop, z którego po scałkowaniu prędkości otrzymujemy kąt obrotu. Enkodery wykorzystywane są głównie do kontroli prędkości obrotowej kół, aby robot obracał się w miejscu bez zbędnego przemieszczenia (jeśli oba koła kręcą się z ta samą szybkością wówczas robot obraca się wokół swojego środka). Aby zminimalizować szanse kolizji robota ze ścianami labiryntu podczas jazdy wykorzystuje się odczyty z trzech typów czujników: odległości, enkoderów oraz żyroskopu. Każda z tych wartości jest uwzględniana z odpowiednią wagą, która została dobrana w sposób eksperymentalny. Wagi nie są jednak stałe, ale zależne od ułożenia ścianek lub ich braku. Do utrzymywania kierunku wykorzystywane są enkodery oraz żyroskop, natomiast czujniki odległości służą do utrzymywania robota w równych odstępach od bocznych ścianek niwelując niedokładności obrotów. Do jazdy na wprost podobnie jak podczas obrotu wykorzystywany jest regulator PD. Innym ważnym aspektem jest pokonywanie zadanego dystansu, jest to długość pojedynczej komórki. Błędy podczas pomiaru odległości mogą skutkować złym zmapowaniem labiryntu bądź kolizją ze ścianką. Korzystając z faktu, że kształt labiryntu jest znormalizowany możemy bazować robota do punktów charakterystycznych (w tym wypadku jest to początek bądź koniec ścianki). Korzystając z bazowania co pewien czas zerowany jest błąd położenia (np. w miejscach pokazanych na rys. poniżej). I na koniec coś co wszyscy lubią najbardziej, czyli robot w akcji. Niestety nie jest to najnowsze wideo, ale na pewno w najlepszej jakości, czyli przejazd robota podczas zawodów ISTROBOT w Bratysławie.
  40. 5 punktów
    Bardzo proszę: https://www.forbot.pl/forum/index.php Pełno tam ciekawych artykułów o elektronice i mechanice, pytań początkujących robotyków, dużo worklogów z budowy interesujących pojazdów no i cała masa dobrych pomysłów na własny rozwój. Są konkursy, ankiety i wielu ludzi gotowych pomóc w potrzebie. Zajrzyj, a nie pożałujesz - na pewno znajdziesz coś dla siebie. Niestety będziesz musiał parę razy kliknąć myszką a widząc Twoje lenistwo nie jestem pewien czy na taki wysiłek jesteś gotowy.
  41. 5 punktów
    Ostatnio zauważyłem duże zainteresowanie tematem wykorzystania laminarek do przenoszenia termotransferu. Temat rozpoczął Nawyk i od tego momentu pojawiały się pytania. Nawyk polecał laminarkę Lervia KH4410, której używał bez przeróbek. Co jakiś czas poszukiwałem na Allegro tego modelu laminarki, lecz nic znaleźć nie umiałem. W końcu jednemu z użytkowników forum (chwalić się, który ) znalazł tą laminarkę - jej nazwa nie jest ujęta w tytule aukcji, stąd problem. Namiary na aukcję: LAMINARKA dwustopniowa na Gorąco i Zimno PODAJNIK Sprzedający: tanieAGD Cena: 59zł bez wysyłki. Bez dłuższego namysłu laminarkę zakupiłem. W paczce była laminarka, "podstawka" (prowadnica?) na papier (która się do płytek nie przyda) oraz po 10 folii w 3 rozmiarach. Wypadła jakaś luźna śrubka, nie wiem gdzie miała przynależeć, ale nic złego się na razie nie dzieje. Sprzęcior wygląda tak: Jak widać zbytniej filozofii nie ma. Z prawej dwa przełączniki, do włączania laminarki oraz przełącznik temperatur (używamy najwyższej). Z lewej strony chwilowy przycisk do zatrzymywania wałków. Po włączeniu laminarki wałki kręcą się cały czas, nagrzanie się do odpowiedniej temperatury jest sygnalizowane przez zielona diodkę nad przełącznikiem. Czas było coś wykonać. Płytka dwustronna, laminat 1,5mm. Dwie warstwy zwyczajowo najpierw spasowałem pod światło, potem złączyłem zszywaczem w kilku miejscach, spłaszczyłem zszywki kombinerkami i między papier wsunąłem wyczyszczony uprzednio laminat. Taki pakiet przeszedł 15 przejść przez laminarkę. Przy niektórych przejściach laminarka trzeszczy, ale nic niepokojącego się nie dzieje - widocznie wałki muszą się nieco rozejść. Filmik (w jakości HD ) pokazuje pojedyncze przejście laminatu przez laminarkę, słychać wyraźnie trzeszczenie: Fragment płytki po zdjęciu papieru kredowego (płytka jeszcze mokra, widać resztki papieru - płytka lądowała później w occie): Wnioski: Laminarka prawdopodobnie posłuży już tylko do płytek, ponieważ wałki po czasie się rozejdą. Przy brzegach nagrzewa słabo - trzeba sobie zostawić margines, ponieważ w przeciwnym wypadku ścieżki przy krawędziach prawdopodobnie odejdą. Zaoszczędzamy sporo nerwów swoich i właściciela żelazka, którego używamy do termotransferu. Płytki są powtarzalne, docisk jest mniej-więcej taki sam na całej powierzchni, przez co nie ma już tak, że na części toner jest rozlany, a gdzie indziej odchodzi. Dokładność lepsza niż żelazkiem, nie próbowałem jakie najcieńsze ścieżki da się wykonać, z tego co pamiętam Nawyk taki test przeprowadzał, zdjęcie jest gdzieś na forum (piwo dla znalazcy ). Podsumowanie: Przydatne narzędzie dla wygodnych, przy większej wprawie bardzo zbliżone efekty można pewnie uzyskać żelazkiem (pytanie - po ilu próbach). Ja osobiście mogę polecić. Aby zamknąć wszystkie pytania na temat zastosowania laminarek do produkcji płytek w jednym miejscu, proszę się pytać w tym temacie.
  42. 5 punktów
    Witam. Po około miesiącu pracy przedstawiam Wam moją pierwszą konstrukcję - Euzebiusza. Linefollower z założenia miał być maksymalnie prosty (BEAM pomijamy oczywiście...). Zrezygnowałem więc z mostka H, a serwa wysterowałem poprzez PWM z ATTINY2313. Początkowo miał to być AT89C4051, gdyż wcześniej programowałem już procesory '51, ale programator do niego przewyższył moje możliwości i po dwóch dniach próby zaprogramowania zrezygnowałem . Przy okazji dodam że moje pierwsze starcie z AVR wygrałem ; ) Podwozie wykonane jest z 8mm plexi, wyciętej u znajomego na laserze. Bardzo fajny materiał to plexi, ale 8mm trochę za ciężkie jest. Kółka jak widać Przyklejone do orczyków, a te na zębatkę serwa. Kółko 'skrętne' to rozwiercone kółko od lego. Napęd to mikroserwa Turnigy TG9. I wybór tego napędu to był błąd. Dwa serwa mają różne prędkości maksymalne, w jedną stronę kręcą się z inną prędkością niż w drugą. Musiałem się nieźle nagimnastykować żeby to jako-tako wykalibrować w programie, a przez to jeździ wolno. Serwa nadają się do przełączania jakichś elementów itd, ale na pewno nie do napędu. Elektronika: Najprościej jak się da. Attiny2313 działający (narazie jeszcze) na wewnętrznym oscylatorze, na dniach będę walczył z zewnętrznym. Mimo rzekomej niedokładności wew. osc. ze sterowaniem serwami nie ma problemu. Programowany w C. Czujniki linii to 3sztuki CNY 70, podłączone bezpośrednio do wejść mikrokontrolera. Nie używam żadnych komparatorów ani ADC, mimo tego robot jeździ po dowolno-czarnym. Zasilany z 4xakumulatorów AA, bez stabilizatora. Proc się nie restartuje (raczej ) i wszystko działa stabilnie. Całość zlutowana na płytce uniwersalnej (PDU14), bardzo bardzo nieestetycznie ) Co do wad konstrukcji - na pewno 3 czujniki to za mało, żeby rozwinąć jakąś sensowną prędkość. Do tego wykrywanie kąta prostego nie zawsze działa jak należy, mimo dostosowania programu pod tym kątem. W dodatku zamontowałem je za blisko i prawie cały czas robot widzi linię dwoma, nawet jadąc na wprost. Czasem się gubi - koła tracą przyczepność, zdarza się że wypadnie z trasy. Kąt prosty również nie zawsze znajduje, czasem przejedzie prosto. Mam też nauczkę na przyszłość, żeby zawsze dokładnie planować konstrukcję, i nie robić niczego na zasadzie 'z tym nie będzie problemów, to jakoś się zrobi'.Zwłaszcza jeśli chodzi o mechanikę, bo ona przysporzyła mi najwięcej problemów. Ale mimo tego i tak jestem zadowolony z tej Euzebiusza jako pierwszej konstrukcji. Nabyłem sporo doświadczenia, i kolejne mam nadzieję że będą mniej... żalowe ? ; ) Chciałem wystartować go na T-BOT'cie, ale zabrakło mi jednego dnia żeby dokończyć program. Byłem tylko jako widz ; ) Pozdrawiam Mazi
  43. 5 punktów
    http://www.itee.uq.edu.au/~wyeth/Publications/acracblm.pdf http://www.robotic.de/?id=42 Na chwilę obecną nic więcej nie wygooglowałem, nie czytałem jeszcze tego, ale w necie jest sporo dokumentacji.
  44. 4 punkty
    Witajcie. Mam do zaprezentowania mój nowy projekt. Zdalnie sterowany robot kroczący z odbiornikiem podczerwieni. Jednostką centralną jest mikrokontroler ATmega8A-PU. Robot porusza się dzięki trzem serwomechanizmom TowerPro SG90. Inspiracją do sposobu chodzenia był robot kroczący Pololu. Robot posiada 6 niebieskich diod. Ich katody są połączone z odpowiednimi pinami mikrokontrolera, dzięki czemu steruję nimi w zależności od wykonywanego ruchu robota. Anody są połączone przez rezystor z nogami robota, te natomiast są połączone z potencjałem dodatnim zasilania. Jako pilota używam telefonu z androidem wraz z aplikacją RCoid. Korzystam ze standardu RC5. Kierunkami poruszania się robota są przód, tył, obracanie w lewo i prawo. Do zatrzymania robota służy dowolna inna komenda. Sterowanie serwomechanizmów odbywa się dzięki programowo stworzonemu PWM na 8 bitowym timerze mikrokontrolera. Tak wygląda kod przerwania od przepełnienia timera: ISR(TIMER0_OVF_vect) { static uint16_t cnt; if(cnt>=r) PORTC &= ~(1<<PC3); else PORTC |= (1<<PC3); if(cnt>=m) PORTC &= ~(1<<PC4); else PORTC |= (1<<PC4); if(cnt>=l) PORTC &= ~(1<<PC5); else PORTC |= (1<<PC5); cnt++; if(cnt>625) cnt = 0; } Zmienne r m i l odpowiadają za położenie poszczególnych nóg zmieniane w pętli głównej programu. Ich zakres mieści się od 17-76 (0.5ms-2.5ms) (0°-180°). Oczywiście zakres pracy jest mniejszy. Dla przykładu dobranymi wartościami dla nogi środkowej są 42 przy oparciu na lewej części, 44 pozycja środkowa, 46 oparcie na prawej części nogi. Zmienna licznika cnt jest porównywana z wartością 625, dzięki czemu uzyskuję częstotliwość 50Hz (8000000Hz/1/256/625=50Hz [20ms] [prescaler=1]). Jeżeli chodzi o kwestie zasilania to zdecydowałem się na użycie czterech zwykłych baterii AAA dających na wyjściu ~6V co zmusiło mnie do użycia przetwornicy Pololu S7V7F5 do zasilania mikrokontrolera. Diody i serwomechanizmy są zasilane bezpośrednio z baterii. Nogi zostały wygięte ze stalowego drutu o średnicy 1.5mm. Do orczyków zostały przymocowane za pomocą stalowego drutu o średnicy 0.3mm. Koniec każdej nogi zalałem gorącym klejem tak, aby zapobiec ślizganiu się robota na gładkiej powierzchni. Lista elementów: mikrokontroler ATmega8A-PU 3x serwomechanizmy TowerPro SG90 przetwornica Pololu S7V7F5 odbiornik podczerwieni TSOP31236 6x diody niebieskie rezonator kwarcowy 8MHz trytki i rurki termokurczliwe druty stalowe o średnicy 1.5mm, oraz 0.3mm płytka stykowa 170 otworów 4x baterie AAA z koszykiem parę rezystorów, kondensatorów i przewodów Zapraszam do śmiałego pisania swoich pytań, opinii i uwag Pozdrawiam, Karol
  45. 4 punkty
    To nie jest poprawna odpowiedź - i nie pisz o rozszerzeniach gnu c bo to nie ma sensu. Fajnie że je znasz, ale mieszasz tylko początkującym w głowach i pokazujesz że nie rozumiesz co znaczy język C. Więc tak dla wyjaśnienia: Język C nie obsługuje zagnieżdżonych funkcji. Są dostępne kompilatory, które "rozszerzają" standard C, czyli dodają coś od siebie, np. obiektowość, konstrukcje zależne od sprzętu, czy też zagnieżdżone funkcje. Ale trzeba pamiętać, że to nie jest język C, tylko pewne implementacje w konkretnym kompilatorze - zawsze można napisać własny i dodać do niego instrukcje których nigdzie indziej nie będzie.
  46. 4 punkty
    Manipulator "Copernicus" to mój najnowszy projekt, model 4-osiowego robota przemysłowego z ssawką podciśnieniową jako efektorem. Bezpośrednim przyczyną rozpoczęcia budowy był zachwyt nad tego typu profesjonalnymi konstrukcjami, typu Kuka, ABB, Fanuc itd., a które można podziwiać między innymi na różnych targach przemysłowych Robot powstawał w ekspresowym jak dla mnie tempie, około 2 miesięcy, a jego budowa nie byłaby możliwa bez wsparcia sponsorów, którym chciałbym w tym miejscu serdecznie podziękować: Agencji Pracy MONDI Polska, która w ramach programu stypendialnego Mondi Wspiera Talenty sfinansowała większość niezbędnych elementów i części; Firmie IGUS Polska, która jako próbkę udostępniła mi przekładnię ślimakową RL-D-30; Firmie STMicroelectronics, dzięki której otrzymałem płytkę Nucleo; Zespołowi Szkół Łączności im. M. Kopernika w Poznaniu, również za pomoc finansowo-merytoryczną. Dobrze, na początek kilka zdjęć ogólnie przedstawiających robota - przepraszam za nienajlepsze tło, zdecydowanie lepiej ideę pracy robota wyjaśniają filmy Konstrukcja jest trójmodułowa, pierwsze cztery zdjęcia ilustrują właściwego robota, piąte przedstawia stację generującą podciśnienie, dwa ostatnie to sterownik robota Mechanika Podstawę robota stanowi prostokąt plexiglass'u 10mm. Pierwsza oś swobody jest pryzmatyczna, składa się z dwóch prowadnic liniowych ø10 i listwy zębatej. Następnie, na wózku z łożyskami liniowymi DryLin, również firmy Igus, znajduje się pierwsza oś obrotowa z wspomnianą już przekładnią ślimakową. Następnie, trzecią oś swobody, a drugą obrotową stanowi silnik z przekładnią planetarną oraz paskiem zębatym HTD. Ostatnią, czwartą oś, służąca ustawieniu ssawki prostopadle do powierzchni, stanowi ssawka podciśnieniowa Festo, bezpośrednio obracana przez silnik krokowy NEMA17. Taki sam silnik napędza przekładnię ślimakową, natomiast w pierwszej i trzeciej osi wykorzystałem, jak wspomniałem, silniki z wbudowaną przekładnią planetarną. Elektronika Sterownik robota jest trójpoziomowy - na pierwszym z nich znajduje się gniazdo trapezowe, sygnalizatory napięć i 2 zasilacze - 24V/8,5A oraz 12V/5A. Ten pierwszy zasila tylko silniki, natomiast drugi - pompkę podciśnieniową, elektrozawór i wszystkie pozostałe elementy, wykorzystując w tym celu przetwornicę step-down (dającą na wyjściu 5V DC - Nucleo wykorzystuje własny, znajdujący się na płytce stabilizator 3,3V). Na drugim poziomie znajdziemy wspomniane Nucleo F103 i przetwornicę, 2 przekaźniki do sterowania pompką i elektrozaworem, płytkę dystrybuującą zasilanie oraz 4 sterowniki silników krokowych TB6560. Na trzecim poziomie - przycisk bezpieczeństwa i 2 wentylatory. Płyty w sterowniku wykonane są również z plexi 5mm. Do połączeń sterownik-robot-stacja generująca podciśnienie używam w większości złącz wielopinowych dedykowanych automatyce. Robot posiada czujniki krańcowe, potrafi się zerować. Oprogramowanie Napisałem program w Arduino IDE, który zawiera kinetykę odwrotną liczoną z zależności geometrycznych oraz korzystając z biblioteki AccelStepper() steruje "na sztywno" wszystkimi czterema silnikami krokowymi. Następnie wpisałem kilkanaście punktów, i tak robot układa krążki i rozkłada, i tak w pętli... Osiągnięcia, dalsze plany i film Aktualnie, robot może pochwalić się wzięciem udziału w RoboDay 2019 (pokazy na Politechnice Poznańskiej) i II miejscem na µBot (zawody organizowane przez V LO Kraków). Projekt jest aktualnie zamknięty, ale myślę nad rozwojem konstrukcji, na przykład dodaniem kamery PixyCam2. Opis jest dość zwięzły - gdybyście mieli jakiekolwiek pytania, chętnie dopowiem szczegóły Pozdrawiam, wn2001
  47. 4 punkty
    Ze względu na cenę, prostotę, wystarczającą do latania jakość i małe opóźnienia systemy FPV posługują się pradawnym standardem telewizji analogowej PAL. Dlatego na wyjściu takiego odbiornika dostajesz sygnał tzw. composite video po jednym drucie i to wprowadzasz do monitora, którym może być zwykły telewizor z odpowiednim wejściem, gogle itp. Jeśli chcesz taki sygnał wciagnąć do komputera (niechby i do Maliny) potrzebujesz tzw. frame grabbera czyli urządzenia, które "rozumie" analogowy sygnał CVSB, "rozpakowuje go" na kolejne ramki obrazu, ew. kompresuje i udostępnia w postaci cyfrowej np. przez USB. Poszukaj hasła "usb frame grabber" lub np. "usb video capture" - powinno pomóc. EDIT: Pierwszy z brzegu: https://rc-planeta.pl/pl/okablowanie-i-akcesoria/666-konwerter-fpv-usb-grabber-konwerter-video.html ale jest tego pełno.Szukaj w sklepach modelarskich albo RTV/AGD w działach video lub na aukcjach.
  48. 4 punkty
    Witam serdecznie, Chciałbym zaprezentować mój projekt którym jest czworonożny robot kroczący sterowany za pomocą kolna arduino - nano V3. Głównym celem powstania tej konstrukcji było zabicie wolnego czasu oraz wykorzystanie nowo zamówionych części. Cały proces tworzenia od koncepcji do gotowego czworonoga trwał poniżej tygodnia. Funkcjonalność robota skupiała się na chodzeniu do przodu oraz pokonywaniu małych przeszkód. Elektronika Do stworzenia projektu potrzebny był kontroler - wspomniane już wcześniej arduino nano lub jego klon. W mojej opinii jest to najbardziej użyteczne arduino do projektów DIY, ze względu na jego małą wielkość i masę oraz identyczne możliwości obliczeniowe jak jego więksi bracia. Arduino zostało zamontowane na płytce rozszerzającej z wieloma wyprowadzeniami dla serw i nie tylko. Ten element jest bardzo uniwersalny i ułatwia podłączenie wielu komponentów bez potrzeby tworzenia odpowiedniej płytki PCB lub używania płytki stykowej. Motoryka została oparta o małe serwomechanizmy - po dwa na nogę, łącznie 8 sztuk. Dodatkowo na końcach nóg zostały zamontowane czujniki krańcowe w celu wykrywania kolizji z podłożem i optymalizacji ruchu. Siła serwomechanizmów okazała się być wystarczająca, jednakże, problemem okazało się być zasilanie. Duża ilość serwomechanizmów działających jednocześnie mocno obciąża arduino, dlatego też, serwomechanizmy powinny mieć własne źródło zasilania. W tym przypadku ograniczenie prędkości ruchów ograniczyło ten problem, ale wskazuje to na popełniony przy projektowaniu błąd. Konstrukcja Konstrukcja składa się z korpusu głównego do którego przymocowano arduino oraz 4 nóg. Jedna noga składa się z dwóch segmentów, a jeden segment z dwóch elementów łączonych śrubą. Lepiej wyjaśni to poniższe zdjęcie. Robot jest tu przedstawiony leżący na swoich plecach. Poniżej znajdują się jeszcze dwa zdjęcia pokazujące jego posturę. W pozycji leżącej, ze wszystkimi nogami skierowanymi względem siebie pod kątem prostym, robot ma przekątną około 30 cm. Powyższe elementy zostały wydrukowane przy pomocy drukarki 3D. Trwało to około 10 godzin. Kod Ze względu na krótki czas rozwoju projektu, jego funkcjonalność nie jest duża. Postało kilka wersji programu, dopasowanych do konkretnego podłoża. Nie różnią się one znacząco, więc przedstawię główny program służący do pokonywania płaskiego terenu w najszybszy i najstabilniejszy sposób. Na początek trochę definicji. Zmienne nazwane są od numeru nogi oraz jej stopnia. Przykładowo tl1 - top-left-1, oraz br2 - bottom-right-2. #include <Servo.h> Servo tr1; Servo tr2; Servo tl1; Servo tl2; Servo br1; Servo br2; Servo bl1; Servo bl2; #define br A1 #define tr A2 #define tl A3 #define bl A4 int i=0; int o=50; int p=20; int h=70; int t=10; int k=0; int l=0; int n=0; int m=0; int timer=0; int d=0; int x=50; int y=50; void setup() { Serial.begin(9600); pinMode(A1, INPUT_PULLUP); pinMode(A2, INPUT_PULLUP); pinMode(A3, INPUT_PULLUP); pinMode(A4, INPUT_PULLUP); tl1.attach(8); tl2.attach(4); bl1.attach(9); bl2.attach(5); tr1.attach(10); tr2.attach(6); br1.attach(11); br2.attach(7); tr1.write(90); tr2.write(75); tl1.write(90); tl2.write(90); br1.write(90); br2.write(90); bl1.write(90); bl2.write(90); } Kolejnym elementem kodu są definicje funkcji. void ltl(int a, int b){ tl1.write(map(a+3, 0, 100, 10, 150)); tl2.write(map(b, 100, 0, 5, 180)); } void ltr(int a, int b){ tr1.write(map(a, 100, 0, 30, 170)); tr2.write(map(b-9, 0, 100, 0, 177)); } void lbl(int a, int b){ bl1.write(map(a, 0, 100, 30, 150)); bl2.write(map(b+1, 0, 100, 0, 178)); } void lbr(int a, int b){ br1.write(map(a, 100, 0, 30, 150)); br2.write(map(b+4, 100, 0, 8, 180)); } void move(){ lbr(100-i,100-k-d); i++; if(i==100){ i=0; k=y; } if(k>0){ if(digitalRead(br)==HIGH){ k--; } } lbl(100-o,100-l-d); o++; if(o==100){ o=0; l=y; } if(l>0){ if(digitalRead(bl)==HIGH){ l--; } } ltr(100-p,100-n-d); p++; if(p==100){ p=0; n=x; l=l+10; k=k+10; } if(n>0){ if(digitalRead(tr)==HIGH){ n--; } } ltl(100-h,100-m-d);; h++; if(h==100){ h=0; m=x; k=k+10; l=l+10; } if(m>0){ if(digitalRead(tl)==HIGH){ m--; } } delay(t); } Przykładowo, nazwa funkcji ltl oznacza leg-top-left i służy do ujednolicenia określania położenia nogi, gdyż niektóre serwa położone są przeciwnie i wysoka wartość sygnału PWM oznacza dla nich przeciwne położenia. Funkcja move to gówna funkcja służąca do poruszania się. Działa ona tak, że wszystkie nogi poruszają się cały czas do tyłu, jednakże, początkowe położenia wszystkich nóg są różne. Gdy noga poruszając się do tyłu dojdzie do płożenia końcowego, podnosi się ona i przemieszcza do maksymalnego płożenia do przodu, wtedy zbliża się ona do podłoża aż do napotkania oporu odebranego przez czujnik krańcowy lub osiągnięcia pozycji maksymalnej, wtedy porusza się znów do tyłu. W ten sposób wszystkie nogi cały czas znajdują się w ruchu, który jest bardzo płynny. Brak 3 stopnia swobody w nodze wpływa jednak na to, że ślizganie jest nieuniknione. Ostatnia część kodu służy jedynie do egzekwowania funkcji move pod pewnymi warunkami. void loop() { if(analogRead(br)==LOW or analogRead(tr)==LOW or analogRead(bl)==LOW or analogRead(tl)==LOW && timer<50){ timer=200; } timer--; if(timer>0){ move(); }else{ lbl(50,50); lbr(50,50); ltl(50,50); ltr(50,50); } } Kod w funkcji loop powoduje również, że w razie podniesienia robota na pewien czas, przestaje on dalej iść. Gdy robot zostanie podniesiony, żaden czujnik krańcowy nie sygnalizuje, że stoi na ziemi, powoduje to spadek licznika timer do 0 i przejście robota w stan spoczynkowy, aż do aktywacji przez ponowne wciśnięcie któregoś czujnika. Gotowy robot Poniżej przedstawiam kilka zdjęć z postępu składania konstrukcji. Niestety nie posiadam dużo zdjęć tego projektu, gdyż serwa i mikrokontrolery szybko zmieniają u mnie właściciela. Podczas testów robot pokonał najwyższy próg o wysokości nieco ponad 4 cm. Może nie jest to imponująca wartość, ale biorąc pod uwagę, że nie może on biegać ani skakać, a maksymalna wysokość własna na jakiej znajduje się jego korpus wynosi około 4,5 cm jest to taki sam wyczyn jak pokonanie przez człowieka, z marszu, przeszkody sięgającej mu do pasa. A tu jeszcze jedno zdjęcie gotowego projektu (słaba jakość, klatka z filmu). Pozdrawiam, i czekam na pytania i porady.
  49. 4 punkty
    A co tu pisać... Ivona to nie jest, zwykły syntezator Klatta, trochę uproszczony (wywalone filtry dla 16 kHz), przystosowany do naszego pięknego języka i przełożony na C++. Kod jest na https://github.com/ethanak/ESP8266-Lektor - muszę poprawić README.md bo się lekko zdezaktualizowało (autorzy uprzejmie poprawili babola w funkcjach i2s). Karmi się go tekstem w utf-8, potrafi sterować np. paskiem led lub serwem od szczęki, może generować predeklarowane kształty ust. Da się skompilować pod Linuksem żeby posłuchać jak gada. Co do dokumentacji... chyba faktycznie coś skopali, bo nie mogę znaleźć paru rzeczy które kiedyś same się pchały w oczy.
  50. 4 punkty
    No cóż... Nie ma czegoś takiego jak "teoria Xweldoga" ale, dzięki za nobilitację. Sądzisz, że nim napisałem bazowy art. Mostki H wcześniej nie zadałem sobie trudu by zbadać f dla PWM na kilku różnych silniczkach ? ( poza niskoindukcyjnymi do Heli ale na początku art. jest podane do jakich silniczków się odnosi co wciąż ignorujesz bo psułoby Ci Twe pesudoteorie ). Sądzisz, że nie zadałem sobie trudu by zmierzyć jaką f stosują producenci wkrętarek tylko, np. jechałem sobie rowerem, wywaliłem się, wyrżnąłem głową o krawężnik i wymyśliłem sobie 200Hz ? Słyszałeś o czymś takim, jak hamowanie elektrodynamiczne ? Rys. A jest poglądowy, nie radzę nikomu silniczkom przełączać obroty z "full prawo" od razu, bez wyhamowania, na "full lewo". Ale popatrz na B i E. W B silnik zawsze po "full" będzie miał zwierane końce. Natomiast w E można przerwać przepływ prądu albo przez przerzucenie przekaźnika albo zaprzestanie podawania PWM. W pierwszym stanie praktycznie natychmiast, w drugim przez chwilę będzie się kręcił bezwładnością ect. Skoro uważasz, że rzekomo nie ma czegoś takiego jak "z" i "bez hamowania" to sam zaproponuj nazwy albo to Ty nie pisz bzdur. Wiem, że np. silniki do wózków inwalidzkich mają osobne uzwojenie do hamowania a piszę to tu by uprzedzić ew. insynuacje że mi się te hamowania pomyliły czy co tam jeszcze jesteś w stanie wymyślić. Tam gdzie wsio jest proste i oczywiste, piszesz b.dużo i niejasno albo po prostu nie wiesz, po co wymyślono i zastosowano PWM. To jest jedyny sposób zmniejszania obrotów silnikom DC z zachowaniem max momentu obrotowego. Zawsze f do PWM wiązałem z małym duty. Zamiast wymyślać jakieś quasi-naukowe teorie nt. rzekomych mych błędów badawczych ( mam Ge na XR2206 chodzący do 1MHz ), zrób to o czym piszę nie wiem już który raz, banalnie prosty test: Ge z duty 20% i zwiększaj jakiemuś typowemu, najczęściej używanemu przez tutejszych forumowiczy silniczkowi ( prócz nich możesz też od heli, na pewno z takiego badania porównawczego będzie większy pożytek niż z całej tej Twej pisaniny ) f od zera do np. 10kHz. Przerasta Ciebie zrobienie tak prostego testu ? Znów Ci się coś pomyliło bo temat z mostkiem na 30A przeniósł się gdzie indziej ale, jeszcze nie skończyłem optymalizacji szczegółów a już masz jakieś "być może". Na jednym forum ( nie podam jakim bo autoreklama ) od dawna jest mój schemat w którym do dużych prądów, prócz transila, zalecam RC. Zdecydowanie więcej pożytku było by dla forumowiczy i mnie, gdybym nawiązał tu merytoryczną dyskusję z kimś kto coś takiego już robił a nie z kimś, kto przypuszcza jak co może się zachować. Drivery ? Do czego ? Do kilkuset Hz ? Stosuj je sobie Ty... Owszem, gdzieś tak w kHz zaczyna się potrzeba ich stosowania ale, do silników z wkrętarek nie są potrzebne kHz.
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...