Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją od 05.04.2014 we wszystkich miejscach

  1. 27 punktów
    Cześć, przedstawiamy Wam naszego pierwszego robota zbudowanego w ramach drużyny Magnat Cyber Forge Team. W skład drużyny wchodzą: mechanik Mateusz Piotrzkowski, elektronik Szymon Zagórnik oraz programista Piotr Krzemiński. Konstrukcja powstawała przez prawie 2 lata - od pierwszej burzy mózgów i szkiców na komputerze, przez zbieranie funduszy, wykonanie elementów, montaż, programowanie, aż do pierwszego startu w konkursie. Robot ma już swoje lata, lecz mimo to postanowiliśmy go tu opisać. Koncepcja i napęd robota Panujący obecnie w robotach sumo trend skłania do wyboru konstrukcji z dwoma kołami napędowymi. Roboty o takiej strukturze napędu są tanie w budowie, a przy tym zapewniają dobre przyleganie krawędzi tnącej ostrza do podłoża. Problemem w ich przypadku jest nieoptymalne przeniesienie ciężaru robota na podłoże oraz duży moment bezwładności robota. Konstrukcja z czterema kołami napędowymi jest mało popularna lecz rozwiązuje wiele problemów robotów wyposażonych tylko w dwa koła. Pierwszą zaletą jest możliwość zapewnienia przeniesienia prawie całego ciężaru robota przez opony. Kolejną zaletą jest przesunięcie środka obrotu robota do przodu oraz łatwość wpadania w poślizg robotem. Zalety te są nieznaczące w obliczu problemów z zamocowanym nieruchomo ostrzem. W przypadku gdy koła stanowią trzy niezbędne punkty podparcia bardzo trudno jest zamocować ostrze z taką dokładnością aby przylegało do podłoża. Zdecydowaliśmy się zaryzykować. Wybór padł na konstrukcję z czterema kołami oraz ruchome mocowanie ostrza - tak aby połączyć zalety struktur napędu z dwoma i czterema kołami. Szukając silników napędu kół robota wybór ograniczyliśmy do 3 firm oferujących jakościowo najlepsze mikrosilniki elektryczne na świecie - firm Maxon, Faulhaber i Portescap. Głównym ograniczeniem determinującym wybór silników do robota minisumo jest ich maksymalna długość. Zdecydowaliśmy że każde z kół będzie napędzane niezależnie, więc długość silnika wraz z przekładnią i enkoderem nie mogła przekroczyć 50 mm. Po przejrzeniu ofert wymienionych firm okazało się że najmocniejszą konfiguracją o wymaganych wymiarach są silniki Faulhaber 1717 006 SR wraz z przekładnią 16/7 14:1 oraz enkoderami IE2. Silniki te są marginalnie mocniejsze od popularnie stosowanych mikrosilników firmy pololu, lecz mają wielokrotnie większą żywotność. Zdarzały nam się sytuacje całkowitego zatrzymania wszystkich 4 silników na regulaminowe 3 minuty walki a silniki dalej pracują jak nowe. Mechanika Konstrukcja robota składa się z 11 elementów. Siedem z nich zostało zoptymalizowanych pod kątem wykonania metodami skrawania z aluminium, stali oraz węglika wolframu. Pozostałe 4 elementy zostały wydrukowane w technologii PolyJet. Głównym elementem konstrukcyjnym jest płyta centralna. Przykręcone do niej są: tulejki mocujące silniki, element mocujący ostrze, mocowania czujników robota przeciwnika oraz płytka drukowana sterująca robotem. Poniżej znajduje się jeden z siedmiu rysunków wykonawczych tego elementu. Element mocujący ostrze wykonano ze stali 40 HM utwardzonej do wartości 50 HRC. Dzięki temu wypolerowana powierzchnia trudno się rysuje, a przeciwnicy gładko prześlizgują się na zamocowane wyżej rogi. Element ten posiada oś obrotu oraz jest dociskany dwoma sprężynami - niezależnie z każdej strony. Sprawia to że ostrze dociśnięte jest równomiernie do podłoża. Ostrza które stosujemy są wykonane dla nas na zamówienie z węglika wolframu. Poniżej zdjęcie porównawcze tego ostrza ze starą wersją zintegrowaną z mocowaniem do płyty centralnej. Felgi robota mają średnicę 24 mm. Posiadamy kilka kompletów z poliamidu i kilka z aluminium. Nie zauważyliśmy większej różnicy w działaniu robota na różnych kompletach. Opony mają zewnętrzną średnicę 30 mm co daje grubość opon równą 3mm. Przetestowaliśmy wiele materiałów na opony od firmy Smooth-On: Mold Star 15, Mold Star 30, Mold Max 20, Vyta Flex 10, Vyta Flex 30, Vyta Flex 20. Ten ostatni wykazał najlepsze własności mechaniczne i jest przez nas aktualnie stosowany. Do mieszanki dodajemy czarny barwnik, co zwiększa nieco nieco lepkość opon. Waga robota waha się w zależności od zastosowanych felg i baterii od 460 do 495 gramów. Elektronika Płyta sterowania robota to laminat FR4 o grubości 0.8mm. By spełnić wymagania związane z fizycznym rozmieszczeniem układów na płytce, wykorzystaliśmy technologię produkcyjną umożliwiającą nam użycie ścieżek o szerokości 0.2mm oraz rastrze podobnej szerokości. Znajdujące się na płytce układy zapewniają prawidłową pracę robota w trybie domyślnym tj. walka na ringu (bez opcji wybierania taktyki i różnych trybów). Program robota wykonywany jest przez wcześniej wspomniany 32-bitowy mikrokontroler ST32F107R8T6. Został on wybrany ze względu na aż cztery dostępne timery, które są niezbędne do obsługi sygnałów z enkoderów silników. Na płycie sterowania znajdują sie również cztery mostki H, złącza od czujników przeciwnika sześć transoptorów i dwa stabilizatory napięcia na 3.3V i 5V. Moduł interakcji użytkownika z robotem stanowi płytka drukowana umieszczona pod górną pokrywą robota. Jest ona w znacznym stopniu mniej skomplikowana od płytki sterującej, niemiej jednak zawiera ona oddzielny mikroprocesor STM32F103CVT. Obsługuje on wyświetlacz OLED o rozdzielczości 128x64 piksele poprzez interfejs SPI. Wykrywa on również sygnał z zmieszczonego na płytce odbiornika podczerwieni oraz czterech przycisków stykowych. Dzięki przyciskom lub bezprzewodowo z pomocą pilota RC5 użytkownik jest w stanie włączyć robota i wybrać algorytm pracy robota wyświetlany na wyświetlaczu OLED. Komunikacja między górnym i dolnym mikroprocesorem odbywa się za pomocą interfejsu UART. Obie płytki drukowane są połączone ze sobą taśmą FFC. Zasilanie Zastosowaliśmy dwukomorową baterię litowo-polimerową, która przy maksymalnym naładowaniu daje 8.4V. Nie wyróżnia się ona niczym szczególnym poza rozmiarem i kształtem, który jest idealnie dopasowany do konstrukcji robota i wewnętrznego rozmieszczenia elementów. Pojemność baterii to 900 mAh Czujniki Sensorami umożliwiającymi wykrywanie przeciwnika są popularne Sharpy GP2Y0D340K. Są to czujniki IR o zasięgu do 40 cm. Są cyfrowe, tj. wskazują pojawienie się obiektu lub jego brak. W środku sensora umieszczony jest układ cyfrowy kondycjonujący otrzymaną wiązkę podczerwieni oraz emitujący cyfrowy sygnał wykrycia do mikrokontrolera. Zasilany jest wyłącznie 5V więc sygnał Vout również jest na tym poziomie. Fakt ten nie komplikuje układu, gdyż użyty mikrokontroler ma wejścia kompatybilne z 5V mimo, że sam jest zasilany na 3.3V. W celu skutecznego wykrywania przeciwnika umieszczono aż 6 sensorów ułożonych w konfiguracji: 2 patrzące do przodu, 2 pod skosem 45 stopni oraz 2 patrzące na boki robota. Jednostki obliczeniowe Dolna płytka zawiera główny procesor STM32F107 taktowany zegarem o częstotliwości 72 MHz. Zajmuje się przetwarzaniem informacji z czujników linii oraz przeciwnika, a także wysterowuje silniki korzystając z wbudowanych fabrycznie enkoderów magnetycznych i regulatora PID. Na górnej płytce znajduje się drugi procesor STM32F103 (również 72 MHz) zajmujący się obsługą wejścia/wyjścia czyli przycisków, wyświetlacza i wbudowanego odbiornika podczerwieni. Taki podział zadań pomiędzy dwa procesory wydaje się zbędny/przesadzony, lecz jest to pozostałość z pierwszych wersji robota.. Programowanie Do komunikacji z robotem użyto dwóch interfejsów: SWD (Serial Wire Debug) – szeregowa odmiana popularnego interfejsu JTAG. Umożliwia on programowanie oraz debugowanie mikrokontrolera sterującego. Do komunikacji między dwoma modułami (mikroprocesorami) oraz komunikacji komputer – mikroprocesor użyto interfejsu UART. Fizyczne połączenie robota z komputerem stanowi złącze MicroHDMI. Zostało ono wybrane ze względu na liczbę dostępnych pinów oferowane przez standard HDMI, trwałość mechaniczną i dostępność. Medium łączące wymienione interfejsy i komputer jest przejściowa płytka drukowana z standardowymi złączami dla programatorów. Rysunek poniżej przedstawia omawianą „przejściówkę”. Oprogramowanie Program dla robota pisany jest w języku C, z użyciem Standard Peripheral Library. W newralgicznych miejscach, aby przyśpieszyć kod, wykonywane są operacje bezpośrednio na rejestrach - dzięki temu został zachowany balans między czytelnością a wydajnością kodu. Jeśli chodzi o IDE, początkowo wykorzystywane było TrueSTUDIO Lite, lecz ze względu na swój limit wielkości programu wynikowego (32 kB?) byliśmy zmuszeni do przejścia na CoIDE. Silniki wysterowywane są regulatorem PID, lecz tak naprawdę tylko człon P jest aktywny. Zaimplementowany został pełny regulator PID, lecz okazało się, że na członie P robot zachowuje się dobrze i nie ma potrzby uaktywniać pozostałych współczynników. Magnetyczne enkodery wbudowane w silnik dostarczają aż 7168 impulsów na obrót, co zapewnia wysoką dokładność. Został wykorzystany wbudowany w STM32F107 interfejs dla enkoderów, dzięki czemu zliczanie impulsów sygnału kwadraturowego odbywa się niejako "w osobnym wątku" - nie są potrzebne przerwania, wystarczy odczytywać położenie koła ze wskazanego rejestru. Dzięki czterem czujnikom linii z przodu, możemy obliczyć w przybliżeniu kąt pod jakim podjeżdżamy do linii. Wystarczy prosta trygonometria - znamy odległość między czujnikami, znamy też dystans jaki robot przejechał od momentu zobaczenia linii zewnętrznymi czujnikami do momentu zauważenia jej czujnikami wewnętrznymi. Znając kąt pomiędzy osią robota a linią, możemy odpowiednio wykonać manewr wycofania się ku środkowi planszy. Odbiornik podczerwieni na górnej płytce służy nam głównie do odbierania sygnałów z pilotów sędziowskich. Zastosowaliśmy własny odbiornik przede wszystkim aby zaoszczędzić na miejscu, lecz również aby móc odbierać niestandardowe komendy dla robota, np. wskazówki dotyczące taktyki. Dzięki "deweloperskiej" wersji aplikacji Sumo Remote możemy wysyłać w zasadzie dowolny kod do robota - po dopracowaniu funkcja ta będzie dostępna publicznie. Monochromatyczny wyświetlacz OLED o rozdzielczości 128x64 umieszczony na górnej płytce umożliwia wybór taktyk, a także wyświetlanie informacji testowych. Nie posiada on wbudowanej czcionki, więc konieczna była implementacja wyświetlania własnych czcionek/obrazków. Aby zaoszczędzić miejsce w pamięci Flash procesora, obrazy kompresowane są algorytmem RLE za pomocą konwertera w postaci aplikacji na PC, po czym na robocie dekompresowane są w locie. Dzięki temu możemy użyć dużych i czytelnych czcionek, czy też schematycznych ikon obrazujących manewry robota. Krótkie demo działania wyświetlacza: (muzyka niestety nie jest odtwarzana z robota ). Po więcej szczegółów zapraszamy na naszą stronę: http://mcft.eu/_portal/page/knowledge_base/cat/6/Enova_MiniSumo#art_Enova_MiniSumo. Osiągnięcia Sezon 2013/2014: 1. miejsce na Roboxy 2014 w kategorii Minisumo 1. miejsce na Trójmiejskim Turnieju Robotów 2014 w kategorii Minisumo Deathmatch 3. miejsce na Trójmiejskim Turnieju Robotów 2014 w kategorii Minisumo 1. miejsce na Cyberbot 2014 w kategorii Minisumo Deathmatch 2. miejsce na Cyberbot 2014 w kategorii Minisumo 1. miejsce na Robot-SM 2014 w Göteborgu w kategorii Minisumo 1. miejsce na Ogólnopolskich Zawodach Robotów ROBOmotion 2014 w kategorii Minisumo 1. miejsce na Ogólnopolskich Zawodach Robotów ROBOmotion 2014 w kategorii Minisumo Deathmatch 1. miejsce na Robotic Tournament 2014 w kategorii Minisumo 1. miejsce na Robotic Tournament 2014 w kategorii Minisumo Deathmatch 1. miejsce na Copernicus Robots' Tournament 2014 w kategorii Minisumo 1. miejsce na Copernicus Robots' Tournament 2014 w kategorii Minisumo Deathmatch 1. miejsce na Robotic Arena 2013 w kategorii Minisumo Debel (z robotem Mirror Mateusza Paczyńskiego) 2. miejsce na Robotic Arena 2013 w kategorii Minisumo Enhanced 2. miejsce na Robotic Arena 2013 w kategorii Minisumo Classic 2. miejsce na Sumo Challenge 2013 w kategorii Minisumo+ 1. miejsce na Sumo Challenge 2013 w kategorii Minisumo 1. miejsce w konkursie robotów Gdańskich Dni Elektryki Młodych 2013 w kategorii Minisumo Sezon 2012/2013: 1. miejsce na Leś-Tech 2013 w kategorii Minisumo 1. miejsce na Roboxy 2013 w kategorii Minisumo 1. miejsce na CybAiRBot 2013 w kategorii Minisumo 1. miejsce na Robocomp 2013 w kategorii Minisumo 1. miejsce na ROBOmotion 2013 w kategorii Minisumo Deathmatch 1. miejsce na ROBOmotion 2013 w kategorii Minisumo 1. miejsce na Copernicus Robots Tournament 2013 w kategorii Minisumo Deathmatch 1. miejsce na Copernicus Robots Tournament 2013 w kategorii Minisumo 3. miejsce na Trójmiejskim Turnieju Robotów 2013 w kategorii Sumo² 1. miejsce na Trójmiejskim Turnieju Robotów 2013 w kategorii Minisumo 1. miejsce na Robotic Tournament 2013 w kategorii Minisumo 1. miejsce na RobotChallenge 2013 w Wiedniu w kategorii Minisumo 1. miejsce na Robomaticon 2013 w kategorii Minisumo 1. miejsce na T-BOT 2013 w kategorii Minisumo 1. miejsce na Robotic Arena 2012 w kategorii Minisumo Enhanced 2. miejsce na Robotic Arena 2012 w kategorii Minisumo Poniższy film prezentuje walki Enovy na konkursie RobotChallenge 2013 w Wiedniu: A tutaj kompilacja walk Enovy z konkursu Robocomp 2013 w Krakowie:
  2. 21 punktów
    Przedstawiam mojego najnowszego robota klasy LineFollower Standard "Fuzzy". Z opisywaną konstrukcją pojawiam się na większości zawodów jakie organizowane są w ostatnim czasie. W porównaniu do moich poprzednich robotów Fuzzy nie został wyposażony w napęd tunelowy. Powodem tej decyzji była chęć testowania nowych algorytmów. Efekty mojej pracy łatwiej zauważyć na robocie bez docisku, ponieważ jest on trudniejszy to wysterowania przy większych prędkościach. Konstrukcja mechaniczna Robot standardowo wyposażony został w dwa silniki Pololu 10:1 HP z obustronnym wałem, na którym zamocowane zostały magnesy od enkoderów. Podwozie stanowi płytka PCB wykonana w Satlandzie. Czujniki wysunięte zostały do przodu na węglowej listewce. Koła wytoczone zostały na zamówienie. Całość, zależnie od dobranego akumulatora waży 70-100g. Elektronika Prezentowana konstrukcja to czwarty prototyp robota. Głównymi elementami części elektronicznej są: mikrokontroler STMF103RBT6, enkodery AS5040 oraz mostek TB6612. Konstrukcja może obsługiwać do 16 czujników KTIR. Po przeprowadzonych testach pozostałem jednak przy 8 transoptorach. Pozostałe połączenia z czujnikami pozwalają na wizualizację ich stanów poprzez diody LED. Schemat prototypu Prototyp W poprzedniej konstrukcji do komunikacji z otoczeniem wykorzystywałem złącza typu Goldpin o rastrze 0.5mm. Częste podpinanie i odpinanie dodatkowego osprzętu sprawiło, że złącza te szybko uległy uszkodzeniu wprowadzałem spore problemów. Dlatego w nowej wersji zastosowałem złącza firmy HARTING Flexicon, które rozwiązały mój problem. Szczerze mogę je polecić, nie miałem żadnych problemów od kiedy je stosuję. Ostateczna wersja elektroniki ze złączami HARTING Flexicon Oprogramowanie Program napisany został w języku C z wykorzystaniem biblioteki dostarczanej przed producenta STMów. Kod w głównej mierze składa się z dwóch części. Pierwsza odpowiedzialna jest za komunikację z otoczeniem, druga za podążanie za linią. Kontroler robota Robot może komunikować się z komputerem lub specjalnym kontrolerem za pomocą interfejsu USART. Możliwa jest również komunikacja przez moduły Bleutooth. Całość obsługiwana jest przez własny, prosty protokół do komunikacji. Algorytm pakuje wszystkie dane w ramki oraz oblicza sumę kontrolną. Rozwiązanie takie pozwoliło na bezbłędne przesyłanie wymaganych danych. Prototyp z modułem BlueTooth Podążanie za linią wykonane zostało w oparciu o 3 regulatory: PD - podążanie za linią, sprzężenie zwrotne od czujników 2x PID - sterowanie faktyczną prędkością silników, sprzężenie zwrotne od enkoderów magnetycznych Efekty Szczególną wagę przykładałem do precyzji przejazdu, która moim zdaniem jest zadowalająca - szczególnie na kątach prostych. Robot wygrał wszystkie zawody w kategorii LineFollower Standard w jakich brał udział. Zdarzyło mu się przegonić również niejednego robota z turbiną. W optymalnych, domowych warunkach średnia prędkość robota, to ponad 2m/s. Poniżej filmik z zawodów RoboMotion z prędkością około 1,4 m/s - nie był to najszybszy przejazd. Ostateczny wygląd robota W chwili obecnej konstrukcja różni się od powyższej jedynie kolorem opon i długością listewki od czujników. Później postaram dodać więcej zdjęć - szczególnie jeśli będzie z Waszej strony zainteresowanie czymś konkretnym. Podziękowania W tym momencie chciałbym podziękować firmom HARTING oraz TME, które wspierały pracy przy tym projekcie. Zachęcam do zadawania pytań, odpowiem praktycznie na każde
  3. 15 punktów
    Witam wszystkich! =) Od dłuższego czasu zbieram się do opisu mojej pierwszej "poważniejszej" konstrukcji. Jako że semestr się dopiero zaczyna i jeszcze jest czas na cokolwiek, a na dodatek w ciągu ostatnich dni została otworzona kolejna edycja konkursu z Proxxonem, przyszedł czas na zrealizowanie tego planu. Tym samym z wielką przyjemnością prezentuję robota mobilnego klasy micromouse: Let Me Out 1. Pomysł Podczas zeszłorocznych wakacji moje zainteresowanie zostało skierowane w kierunku dwóch zagadnień: roboty klasy micromouse oraz silniki krokowe. Z tego pierwszego bardzo szybko podjąłem decyzję o budowie takiego robota. Interesując się zaganieniem drugim (silników krokowych), dowiadując się o ich możliwościach i ograniczeniach zacząłem się zastanawiać nad ich wykorzystaniem w robocie klasy micromouse. Niestety, przewalając internet dniami i nocami nie znalazłem żadnego sensownego opisu zrealizowanej i zbadanej konstrukcji napędu robota mobilnego opartego na silnikach krokowych. W ten sposób narodził się pomysł o zaprojektowaniu, zbudowaniu i przetestowaniu takiego rozwiązania. 2. Założenia projektowe • Spełnienie podstawowych warunków konstrukcyjnych oraz programowych zawartych w regulaminie konkurencji micromouse. Robot projektowany był tak, żeby mógł wziąć udział w zawodach w Polsce. • Oparcie projektu o procesor z rodziny AVR W tamtym momencie STM-y dopiero wynurzały mi się zza horyzontu, więc zdecydowałem się na popularnego AVR-a, którego już dobrze znałem i umiałem go programować. • Konstrukcja umożliwiająca poruszanie się po skosie labiryntu Aby móc zastosować bardziej złożone algorytmy przemierzania labiryntu. • Zastosowanie silników krokowych jako napęd główny robota • Umożliwienie bezprzewodowej komunikacji z robotem Głównie w celu odbierania danych o aktualnym stanie zmapowania labiryntu przez robota i możliwości wizualizacji aktualnej sytuacji na komputerze. • Zaprojektowanie płytki PCB w sposób umożliwiający wykonanie jej metodą fototransferu Oczywiście w celu zaoszczędzenia na czasie i funduszach, zdecydowałem się na warsztatową metodę wykonywania płytki. • Implementacja algorytmu pozwalającego na rozwiązywanie algorytmu metodą "floodfill" 3. Konstrukcja Mechaniczna 3.1 Napęd 3.1.1 Silniki Jako napęd zdecydowałem się na użycie silników krokowych. Zalety silników krokowych (+) Sterowanie pozycją - dokładne sterowanie w otwartej pętli sterowania (+) Silnik pracuje z pełnym momentem w stanie spoczynku (+) Żywotność silnika wyznaczona wytrzymałością łożysk i cewek - brak szczotek Wady silników krokowych (-) Przeznaczone do pracy z małymi prędkościami (-) Możliwość wystąpienia zjawiska "gubienia kroków" (-) Duża emisja ciepła (-) Duża masa i rozmiary (-) Skomplikowany sposób sterowania Ze wszystkich silników krokowych dostępnych na polskim rynku, silniki o kodzie producenta S20STH30-0604A firmy Pololu najbardziej nadawały się do projektowanej konstrukcji. Porównanie parametrów wybranych silników krokowych z popularnymi mikrosilnikami Pololu Parametr • Silnik krokowy • Mikrosilnik Pololu 30:1 Waga • 60g • 10g Wymiary • 20 x 20 x 30 mm • 10 x 12 x 24 mm Napięcie zasilania • 3.9 V • 3-9 V Pobór prądu • 600 mA • 120-1600 mA Moment obrotowy • 140 g*cm (0.017 Nm) • 600 g*cm (0.059 Nm) Średnica wału • 4 mm • 3 mm Cena • 100 zł • 70zł Sterowanie • Trudne • Proste Problemy do rozwiązania w projektowaniu napędu opartego o silniki krokowe: Problem: Silniki krokowe przeznaczone są do pracy przy niewielkich prędkościach obrotowych (zazwyczaj 4-10 RPS to ich maksymalne osiągi). Rozwiązanie: Zasilanie silników z dużo wyższego napięcia (w tym wypadku 24 V). Pozwala to na skrócenie czasu narastania prądu na cewkach, prez co można je przełączać częściej, w efekcie uzyskując wyższą prędkość obrotową. (Udało mi się rozkręcić te silniki do 45 RPS - w powietrzu, nie na jadącym robocie) Problem: W robocie potrzebne jest napięcie 24 V Rozwiązanie: Zasilanie silników z przetwornicy step-up, generującej 24 V z napięcia zasilania (7.4 V bądź 15.8 V) Problem: Zasilając silnik z wyższego napięcia, prąd na cewkach będzie proporcjonalnie większy, co po przekroczeniu wartości nominalnej (600 mA) prowadzić będzie do ich spalenia Rozwiązanie: Zastosowanie gotowego modułu sterownika silnika krokowego z ogranicznikiem prądu (funkcja Chopper) 3.1.2 Koła Jako koła wybrano gumowe koła firmy Solarbotics o średnicy 2.8 mm i szerokości 13 mm. Koła mają świetną przyczepność i doskonale nadają się do tego zastosowania. Jedyną jak dotąd zaobserwowaną wadą jest bardzo duża zdolność do zbierania kurzu i drobnych odpadów, przez co jazda po zabrudzonej powierzchni bardzo szybko doprowadza do zmniejszenia przyczepności kół. 3.1.3 Mocowania silników Niestety na rynku nie istnieją mocowania do silników krokowych w tym rozmiarze (Nema 8), więc musiałem takie mocowania wyprodukować sam. Mocowania silników zostały zaprojektowane w programie TinkerCad dostępnym w wersji przeglądarkowej. Zamówienie przyjęło i wykonało techniką druku 3D koło naukowe działające przy Politechnice Wrocławskiej "Rapid Troopers". Mocowania zawierają 4 otwory na śruby mocujące silnik do elementu, oraz 4 otwory na śruby służące do przytwierdzenia silnika wraz z mocowaniem do platformy. 3.1.4 Podwozie Jako podwozie wykorzystałem płytkę PCB z elektroniką, przedstawioną w dalszej części artykułu 4 Elektronika Schemat elektroniczny jak i płytka PCB zostały zaprojektowane w programie CadSoft Eagle. 4.1 Zasilanie Robot może być zasilany z jednego bądź dwóch (połączonych szeregowo) akumulatorów Li-Po 7.4 V o pojemności 250 mAh. Dwa akumulatory stosowane są w celu podwyższenia napięcia na wejściu przetwornicy, co skutkuje obniżeniem poboru prądu z akumulatora i wydłużeniem możliwego czasu działania robota. 4.1.1 Zasilanie silników Silniki zasilane są napięciem 24 V podawanym z przetwornicy step-up opartej o układ XL60098. Przy pracy pobierają 1 - 1.2 A. 4.1.2 Zasilanie logiki Wszystkie układy logiczne zasilane są napięciem 5 V uzyskiwanym z przetwornicy step-down D24V6F5. Powodem zastosowania przetwornicy zamiast stabilizatora liniowego jest różnica napięć na wejściu i wyjściu układu. Występuje tu obniżenie napięcia z ~16 V do 5 V, co przy stabilizatorze liniowym generowałoby bardzo duże ilości ciepła i mogłoby prowadzić do jego uszkodzenia lub poparzenia użytkownika podczas obsługi robota. 4.2 Procesor Jednostką sterująca całego robota jest ośmiobitowy procesor AVR Atmega 128 firmy Atmel, taktowany zewnętrznym kwarcem 16 Mhz. Procesor zasilany jest napięciem 5 V. W celu zmniejszenia rozmiarów robota, zastosowano procesor w obudowie TQFP64. 4.3 Czujniki odległości Jako czujniki odległości zastosowano diodę LED SFH4550 działającą w paśmie podczerwieni. W robocie umieszczono 6 takich zestawów. Dwa skierowane w przód, dwa na boki oraz dwa odchylone od diametralnej robota o 45°. Prąd płynący przez diody IR to 95 mA, co daje wystarczające natężenie światła do dokładnego odczytywania odległości przy jednoczesnym braku konieczności uważania na przepalenie się diody spowodowane długim świeceniem przy zbyt dużym prądzie. 4.4 Sterowniki silników Zastosowano sterowniki firmy Pololu oparte na modula A4988. Sterowniki pozwalają na pracę w trybach: pełnokrokowym, półkrokowym, ćwierćkrokowym, 1/8 oraz 1/16 kroku. Funkcja ograniczania prądu (chopper) pozwala sterować silniki wyższym napięciem bez ryzyka uszkodzenia cewek silnika. Kolejną zaletą zastosowania sterowników silników krokowych jest możliwość sterowania silnika za pomocą tylko jednego pinu (tylko jeden pin mikrokontrolera podaje sygnał częstotliwościowy odpowiedzialny za taktowanie silnika). W celu umożliwienia generowania sygnałów o różnej częstotliwości, każdy ze sterowników obsługiwany jest przez inny timer. Obydwa szesnastobitowe timery sterujące działają w sprzętowym trybie Clear on Compare Match. Pozwala to na automatyczne generowanie sygnału o zadanej częstotliwości bez udziału samej jednostki obliczeniowej. 4.5 Interfejs komunikacyjny Jako interfejs komunikacyjny robota służą dwie diody LED, buzzer, interfejs UART wraz z modułem bluetooth HC-05 oraz dwa przyciski. Programowanie robota realizowane jest poprzez interfejs SPI. 4.6 Płytka PCB Płytka PCB na której zostały umieszczone wszystkie elementy robota została zaprojektowana za pomocą programuy CadSoft Eagle. Długość: 101 mm Szerokość: 94 mm Płytka pełni jednocześnie funkcję podwozia robota. Takie wymiary pozwalają na swobodny obrót robota w miejscu między ścianami, oraz jazdę po skosie w labiryncie. Płytka w swoim kształcie jest symetryczna, lecz główna masa elementów skupiona została przy tylnej części. Powoduje to brak efektu kołysania się robota ze względu na dociśnięcie tyłu do podłoża. Płytka została stworzona metodą fototransferu oraz wytrawiona w warunkach domowych. Otwory wykonano na wiertarce stołowej. Prostokątny otwór na środku płytki jest miejscem na wystające elementy silników, w których znajdują się gniazda przewodów zasilających. Warstwa Top zawiera wszystkie układy scalone, czujniki, silniki, akumulatory i złącza. W przedniej części robota znajdują się czujniki, mikrokontroler, układ ULN2003 (sterowanie diodami LED) oraz jeden z akumulatorów. Z tyłu umieszczono sterowniki silników krokowych, obydwie przetwornice, moduł bluetooth, drugi akumulator oraz buzzer. Silniki znajdują się w osi symetrii robota Na dolnej stronie płytki umieszczono jedynie kilka rezystorów oraz slizgacz, znajdujący się w diametralnej robota, w jego tylnej części. Zdjęcie poniżej pokazuje stopień upakowania elementów i modułów w robocie. 5 Oprogramowanie Główną częścią projektu było rozwinięcie oprogramowania związanego z obsługą peryferii oraz algorytmem rozwiązującym labirynt. Program napisany został w języku C. 5.1 Pomiary odległości Pomiar z każdego z czujników dokonywany jest z częstotliwością 200 Hz. Zastosowano pomiar różnicowy z uśrednianiem wyników. 5.2 Sterowanie prędkością robota Prędkość robota sterowana jest częstotliwością sygnału podawanego na sterowniki silników. 5.3 Algorytm Zaimplementowany algorytm opiera się na algorytmie Dijkstry, służącym do znajdywania najkrótszej drogi w grafie. 6 Podsumowanie Projektowanie, budowa oraz zaprogramowanie robota zostały zrealizowane zgodnie z założeniami. Robot dobrze radzi sobie w labiryncie. 6.1 Sprawność silników krokowych w robocie mobilnym Podczas jazdy kroki są gubione dość rzadko, co pozwala na wystarczająco dokładne wysterowanie robota w otwartej pętli sterowania z kompensacją pozycji od czujników odbiciowych. Osiągane maksymalne prędkości podczas testów (oczywiście poza labiryntem i po prostej) sięgają 2 m/s. Głównymi wadami tych silników w robocie są ich masa, wielkość, konieczność stosowania sterowników silników krokowych oraz wyższego napięcia. Kolejną wadą jest konieczność ograniczania przyspieczeń, w celu zminimalizowania gubionych kroków. Zaletą stosowania silników krokowych jest brak konieczności stosowania sprzężenia zwrotnego w postaci enkoderów obrotowych. Sterowanie robotem klasy (2.0) w otwartej pętli regulacji Sterowanie w otwartej pętli regulacji z wykorzystaniem silników krokowych jest możliwe. Rozwiązanie to jest wygodniejsze i prostsze do zrealizowania, aczkolwiek posiada bardzo dużą wadę, w postaci braku informacji o gubionych ktokach. Cała kalibracja pozycji opierać musi się na odczytach z czujników odbiciowych. Budowa tego robota z pewnością przyczyniła się do znacznego poszerzenia mojej wiedzy na temat budowy robotów mobilnych, projektowaniu schematów elektronicznych oraz płytek PCB, kategorii micromouse oraz silników krokowych. Niestety nie miałem dostępu do pełnowymiarowego labiryntu, dlatego filmiki z testów są tylko na ćwiartce labiryntu. Robot jeździ wolno, bo w momencie kiedy zaczął działać i poprawnie rozwiązywać labirynt, semestr zaczął być tak gorący że musiałem porzucić prace nad jego rozwojem i zająć się studiami. Na pewno może jeździć o wiele szybciej - pozostaje tylko kwestia gubienia kroków. Zeby pokazać w sumie clue sprawy związanej z zastosowaniem silników krokowych, poniżej filmik na którym robot jedzie z wyłączonymi czujnikami, z wgraną na stałe sekwencją (prosto, prawo, lewo, prosto itp.) Widać jak dokładne może być pozycjonowanie się na silnikach krokowych (które i tak dobierane było "na oko"). Jazda bez sprzężenia od czujników A tutaj testy na labiryncie. Robot rozwiązujący labirynt Nie chcę się już bardziej szczegółowo rozpisywać na poszczególne tematy, żeby artykuł nie rozrósł się do rozmiarów nieczytelnych. Jeśli kogoś interesują detale budowy tego robota i używania tego napędu, zapraszam do dołączonej w załącznikach prezentacji oraz raportu z budowy robota. Jeśli jesteś zainteresowany schematami elektronicznymi tego robota - napisz w komentarzu. KoNaR - Bartlomiej Kurosz - Micromouse Let Me Out.pdf Zastosowanie silnikow krokowych w robotach mobilnych.pdf
  4. 14 punktów
    Cześć! Mimo że Forbota przeglądam od dawna, to jako użytkownik raczej się nie udzielałem, tak więc witam wszystkich. Przyznam się bez bicia że post ten powstał za sprawą konkursu z Proxxonem w roli głównej ^^. Nie jestem pewny czy prezentowana konstrukcja nadaje się na to forum, bo ani toto nie jeździ, ani nie działa na pilota, ale pomyślałem sobie: pokażę, w końcu ma silniki . Chciałbym przedstawić Wam Wykresiarkę - prosty ploter powstały z zalegających w domu "śmieci". Jak sugeruje nazwa, przeznaczony jest głównie do rysowania wykresów do szkoły, ale jego możliwości są nieco większe. Na wstępie zaznaczę, że maszynka cechuje się dość nietypowymi rozwiązaniami: zrezygnowałem z używania "oklepanego" oprogramowania sterującego i dedykowanych sterowników dla silników krokowych. Zamiast tego wykorzystuję własną aplikację okienkową (głównie ze względu na projektowanie wykresów), a całe sterowanie mechaniką zostawiłem dla ATmegi16 i najprostszych końcówek mocy (ULN2803 i L293D). Na początek kilka fotek gotowej maszynki oraz krótka prezentacja działania: Mechanika Zaczęło się od zbierania różnych "przydasiów" wymontowanych ze starych drukarek i skanerów. Trochę to trwało, ale ostatecznie zebrałem: jeden silnik unipolarny, jeden bipolarny, do tego elektromagnes z dźwignią i zasilacz dwunapięciowy (16V i 32V). W przypadku silników konieczne było odszukanie takich ze zintegrowaną przekładnią i paskiem napędowym. Musiały też mieć taką samą rozdzielczość na wyjściu - w przypadku starych skanerów jest to zazwyczaj 300dpi. Mając to wszystko, zaprojektowałem model i na jego podstawie zleciłem elementy montażowe do wycięcia laserem w pleksi 3mm. Wykorzystałem kulkowe prowadnice do szuflad o długości około 310 mm, które po zmianie smaru zaczęły jako tako chodzić. W roli krańcówek osi X i Y użyłem zwykłych przycisków od myszek komputerowych. Na zdjęciu widać także laminat bez miedzi, który przydał się do przyciskania krańcówek, wyrównywania kartki i innych. Całość została zamontowana na płycie meblowej, a do przytrzymywania kartki użyłem folii magnetycznej (takiej na reklamy samochodowe) i małych magnesów neodymowych. Jeśli chodzi o samą budowę, to nie chcę zanudzać. Ogólnie nie mam zbyt dobrze wyposażonego warsztatu, więc musiałem całość rozplanować tak by można to było łatwo zmontować. Elementy kleiłem na super glue, wikol lub żywicę epoksydową. Oczywiście nie zabrakło też starego dobrego "termogluta"... Sterownik Tak jak wspominałem, wszystkim steruje ATmega16. Przede wszystkim zajmuje się ona sterowaniem silnikami krokowymi (poprzez scalaki ULN2803 i L293D) i elektromagnesem osi Z (przez MOSFET z logiką 5V, dokładniej IRLML2502). Poza tym musi też obsługiwać krańcówki, LCD (służył głównie do debugowania) czy komunikację z komputerem. W przypadku tej ostatniej wykorzystałem sytuację do napisania czegoś w rodzaju protokołu (mopsioCODE ), który pozwala zarówno na przesyłanie komend, jak i surowych danych. W wielkim skrócie, dzięki kontroli CRC16 umożliwia automatyczną retransmisję w przypadku błędu transmisji; obsługuje również kody błędów, a także wartości zwrotne które funkcja może odesłać do komputera. Więcej można o tym poczytać w pliku README w kodzie źródłowym. Komunikacja odbywa się przez UART z zastosowaniem scalaczka FT232RL. Postanowiłem też użyć separacji galwanicznej przez 2 transoptory TCMT1109 dla lepszego bezpieczeństwa układu (raz w trakcie testów spaliłem uC). Aplikacja na PC Ten program to mój debiut w Visual C# Express 2010, więc na pewno nie jest idealny. Jego głównym przeznaczeniem jest projektowanie wykresów i automatyczne ich rysowanie (wysyłanie odpowiednich komend do maszyny). Program zajmuje się też parsowaniem plików HPGL, więc można coś narysować w Inkscapie a potem wysłać to do plotera. Obsłużyłem tylko podstawowe komendy, więc pliki generowane przez inne programy mogą nie być poprawnie interpretowane, ale nic nie stoi na przeszkodzie by dopisać resztę. Podsumowanie Ogólnie problemów było dużo, a całość nie działa idealnie. Taki sposób sterowania nakłada pewne ograniczenia, np. rozdzielczość przekładni musi być identyczna. Sterowanie silnikami przez tranzystory i mostek H nie jest zbyt efektywne - mały prąd przy większych częstotliwościach ogranicza prędkość maksymalną, z kolei przy mniejszych prędkościach wydziela się dużo ciepła. Jednak tak jak wspomniałem, projekt powstał w celach edukacyjnych, żeby zobaczyć jak to wygląda w praktyce - samemu napisać skalowanie osi, komunikację, sterowanie i aplikację do projektowania. Tak więc śmiało można powiedzieć że liczyłem się z takim rezultatem i nie jestem zaskoczony... Niemniej jednak ploter sprawuje się całkiem dobrze: spełnia swoje zadanie i jest tani. Osobiście zmieściłem się w 60 złotych - głównie było to wycinanie pleksi, prowadnice i folia magnetyczna pod kartkę. W załącznikach dodaję wszystkie materiały - pliki EAGLE'a dla sterownika, kod źródłowy ATmegi w C, aplikacja sterująca oraz jej kod w Visual C#. Dzięki za uwagę i zapraszam do dyskusji! Jeśli macie jakieś pytania to chętnie odpowiem . Pozdrawiam mopsiok //dodane 03.04.15 Wykresiarka_pliki.rar
  5. 13 punktów
    Większość osób myśląc o cyfrowej telekomunikacji, myśli o współczesne mikroelektronice: smartfonach, komputerach i Internecie. Nie każdy zdaje sobie sprawę z tego, że idea przesylania informacji zakodowanej w ciągach zer i jedynek jest dużo, dużo starsza. Pierwszym urządzeniem tego rodzaju był telegraf skonstruowany przez Emille'a Baudot w latach siedemdziesiątych XIX wieku. Urządzenie po stronie nadajnika posiadało klawiaturę złożoną z pięciu przycisków, które operator musiał wciskać w różnych kombinacjach. Urządzenie wysyłało na linię ciąg impulsów, odpowiadających wciśniętej kombinacji. Odbiornik interpretował ten sygnał drukując na papierowej taśmie odpowiednią literę lub cyfrę, w jej naturalnej formie. Na początku XX wieku idea to została udoskonalona. Nadajnik został wyposażony w klawiaturę podobną do tych stosowanych w maszynach do pisania. Tak narodził się dalekopis. Transmisja danych pomiędzy tymi urządzeniami przypominała standardowy interfejs szeregowy. Z tą różnicą, że z przeciwieństwie do TTL UART-a czy RS323 poszczególne stany logiczne nie były kodowane przez wartości napięć, ale przez fakt przepływu (bądź nie) prądu w obwodzie. Normalnie przez linię płynął prąd o ustalonej wartości (zazwyczaj 60, 40 lub 20 mA). To był stan domyślny. Rozpoczęcie nadawania kolejnego znaku wymagało nadania bitu startu, czyli chwilowego przerwania obwodu. Potem nadajnik oczekiwał na pięć bitów z kodem znaku w alfabecie Baudot (zwanym także międzynarodowym alfabetem telegraficznym). Na końcu pojawiały się bity stopu w trakcie których odebrany znak był drukowany na papierze. Ktoś zapewne zauważył już, że używając pięciu bitów można było zakodować maksymalnie 32 znaki - zdecydowanie za mało, aby pomieścić wszystkie litery alfabetu, cyfry i znaki interpunkcyjne. To prawda. Stosowano pewną sztuczkę - dwie kombinacje bitów były zarezerwowane do przełączania pomiędzy dwoma rejestrami zawierającymi litery oraz cyfry i inne znaki. Ne stosowano także rozróżnienia na male i duże litery. Dalekopis chociaż w pełni cyfrowy, był urządzeniem elektromechanicznym, radzącym sobie bez pojedynczego tranzystora (chociaż oczywiście w latach osiemdziesiątych i dziewięćdziesiątych produkowano nowoczesne, elektroniczne wersje). Dalekopisy były powszechnie używane do przesyłania wiadomości przez wojsko i państwowe służby. Poczta wykorzystywała je do transmisji telegramów. Stosowano je także w roli terminali komputerowych, przed pojawieniem się monitorów CRT. Ślad tej zaszłości historycznej zachował się w nomenklaturze stosowanej w systemach uniksowych, gdzie terminal jest oznaczany skrótem TTY - od angielskiego słowa "teletype", czyli właśnie dalekopis. Przepraszam za ten przydługi wstęp, nie byłem jednak pewien, czy wszyscy będą jeszcze kojarzyć o jakie urządzenie chodzi... Przechodząc do sedna sprawy. Na co dzień pracuję w krakowskim Muzeum Inżynierii Miejskiej. Jakiś czas temu został nam przekazany dalekopis T100, wyprodukowany w latach siedemdziesiątych w Czechoslowacji, na licencji Siemensa. Ponieważ posiadaliśmy już taki eksponat, zostałem poproszony o sprawdzenie możliwości uruchomienia go i wykorzystywania w roli interaktywnej instalacji, zamiast "martwego" eksponatu ukrytego w muzealnej gablocie. Tak rozpoczęły się moje eksperymenty. Najpierw skonstruowałem prosty interfejs USB, oparty na starym mikrokontrolerze AT89C2051 i układzie FTDI. Do generowania pętli prądowej 40 mA używałem zestawu kilku baterii 9V oraz rezystorów o dużej mocy. Komunikacja z dalekopisem ruszyła bez problemu - pojawiła się jednak inna trudność. Okazało się, że uszkodzony jest moduł wzywaka - urządzenia odpowiedzialnego m.in. za zdalne włączanie silnika dalekopisu przy połączeniu przychodzącym, sygnalizowanym odwróceniem kierunku przepływu prądu w linii. Naprawa tego modułu okazała się bardziej skomplikowana niż początkowo sądziłem, ostatecznie postanowiłem więc wymontować wadliwą część i sterować silnikiem za pomocą przekaźnika, zamontowanego w moim interfejsie. Finalna wersja interfejsu zawiera mikrokontroler PIC32MX270F256B oraz moduł GSM SIM800L. Wykorzystałem także 2MB pamięć SPI flash, do wykonywania elektronicznej kopii przychodzących wiadomości. W osobnej obudowie znajduje się generator pętli prądowej, złożony z zasilacza transformatorowego oraz zestawu kondensatorów. Całość można obecnie oglądać na wystawie "Uwaga! Nieprzyjaciel podsłuchuje." w Muzeum Inżynierii Miejskiej w Krakowie. Po wysłaniu SMS-a na podany numer można oglądać dalekopis podczas pracy.
  6. 13 punktów
    Witam po dłuższej przerwie, z tego co kojarzę to mój pierwszy post na Forbocie - wcześniej pisałem jeszcze na dioda.com.pl. Przedstawiam projekt inteligentnej kawalerki oparty o Raspberry Pi i kilku modułów pracujących w magistrali I2C i 1wire. Umożliwia on na automatyzację instalacji elektrycznej mieszkania poprzez m.in. sterowanie oświetleniem przez dedykowaną aplikację www, rozszerzenie funkcji przycisków światła w mieszkaniu poprzez niezależne przypisywanie funkcji np.gaszenie wszystkich świateł włącznikiem przy łóżku, a zapalanie tylko oświetlenia dodatkowego. Monitorowanie temperatury w pomieszczeniu i na zewnątrz, oraz informowanie komunikatami głosowymi o zdarzeniach. System jest elastyczny i modyfikowany w zależności od zachcianek użytkownika, dzięki czujce ruchu, możemy np. w zaprogramowanych nocnych godzinach delikatnie rozjaśniać światła dekoracyjne, nie oślepiając zaspanego nocnego marka. Innym przykładem który pojawił się podczas używania systemu, było wysłanie diodą IR sygnału do włączenia się telewizora po wejściu do mieszkania, lub w przypadku braku użytkowników w mieszkaniu i zwiększonym zużyciu prądu (np zostawione żelazko) - poinformowanie i wyłączenie sprzętów. Ilość możliwych funkcji do zrealizowania jest ogromna niestety każda kolejna powoduje dodatkowe koszty. O ile część modyfikacji można wykonać małym kosztem - jak wspomniane sterowanie ir, to już realizacja pomysłu zabezpieczenia łazienki przed zalaniem poprzez sensor wody i elektrozawór na głównym przyłączu wodociągowym wiąże się z dodatkowym nakładem pracy. W projekcie użyłem popularnych i wspieranych przez społeczności użytkowników części oraz oprogramowania. W krótkim wstępie nie sposób wymienić wszystkich funkcjonalności i drobnych smaczków o których sam dopiero sobie przypominam. W dalszej cześci opiszę działanie całego systemu od strony programowej i sprzętowej oraz udostępnię kody źródłowe strony www i skryptów odpowiedzialnych za automatykę wraz z obrazowym poradnikiem jak to wszystko uruchomić. Mam nadzieje że dam radę bo trochę tego się uzbierało, na początek film z działania: Część sprzętowa. Pierwszym etapem prac było przerobienie instalacji elektrycznej w mieszkaniu. Tutaj głównym założeniem było wykorzystanie standardowych pojedynczych bistabilnych przycisków i pociągniecie wszystkich przewodów włączników i punktów oświetleniowych do jednego punktu. Gniazda zasilające zostały podzielone na 3 sekcje - kuchnia, sprzety rtv, łazienka. Punktów oświetleniowych jest 5, włączników razem z dzwonkiem na zewnątrz również 5. Do włączników został pociągniety przewód 2 x 1.5mm2, tak aby w przypadku demontażu systemu, można było podłączyć wszystko na stałe. Przewody do punktów oświetleniowych 3x1.5mm2, 3 linie gniazd zasilających 3x2.5m + dodatkowy przewód 5x2.5mm2 do trójfazowego zasilania kuchni. Do centralnego punktu zostało doprowadzone 5 sztuk skrętki cat.5 i wyprowadzone odpowiednio do: łazienki, kuchni, routera, oraz dwóch rogów pomieszczenia. Skrętka umożliwia podłączanie do całego systemu np. czujników w magistrali 1-wire, czy sterowanie sygnałem PWM układami mocy oświetlenia ledowego. Łacznie wykorzystałem około 150metrów przewodów. W skrzynce rozdzielczej zamontowane zostały zabezpieczenia oraz listwy rozdzielcze umożlwiające podłączanie urządzeń do układów wejść - wyjść. Poniżej zdjęcia z procesu wymiany instalacji elektrycznej. Cześć sprzętowa - elektronika. Tutaj zastosowane zostały: - Raspberry Pi - jako główny mózg całego systemu - Moduł 8 wejść - wyjść firmy Kamami. - Moduł przetwornika A/C firmy Adafruit. - Moduł 16 wyjść PWM firmy Adafruit. - 2 Czujniki temperatury DS18B20 - Konwerter napięć 3.3 <> 5V - Moduł 4 przekaźników. - 2 Moduły transystorów mosfet do sterowania ledami. - Głośniki komputerowe zasilane z USB Wszystkie podłączenia wykonane zgodnie ze standardowymi przykładami danych modułów czy czujników nie ma tu jakiś skomplikowanych połączeń - wszystkie moduły pracują na magistrali I2C przy zasilaniu 5V - dlatego potrzebny był dodatkowy konwerter napięć tak aby można było podłączyć magistralę do 3.3 woltowego Raspberry Pi. Czujniki na magistrali 1wire spokojnie dają radę przy 15 metrowej skrętce podłączone bezpośrednio pod RPI. Wykorzystane oprogramowanie. - Framework WebIOPi. Głównym frameworkiem użytym w projekcie jest WebIOPi. Jest to gotowa aplikacja dedykowana dla komputera RaspberryPi pozwalająca na sterowanie podłączonymi do niego urządzeniami za pomocą strony internetowej lub skryptów działających w tle. Framework dostępny jest w postaci gotowej paczki instalacyjnej dla systemu linux. Aplikacja uruchamia na komputerze serwer www, na którym możemy uruchomić stronę internetową, a z jej poziomu sterować poszczególnymi urządzeniami. WebIOPi pozwala na sterowanie i monitoring ponad 30 urządzeń pracujących zarówno na magistrali I2C jak i 1-Wire. Framework rozdziela układ sterowania na dwa podstawowe elementy – część sterowania i monitoringu dostępną z poziomu przeglądarki dla użytkownika oraz część komputera, pracującą niezależnie. Skrypty wykonywane na komputerze napisane są w języku Python. Framework pozwala na pracę wielu skryptów jednocześnie. Od strony przeglądarki wykorzystana jest technologia jQuery. Użyłem wersji 0.7 webiopi. Więcej na temat samego farameworka znajdziecie tutaj: http://webiopi.trouch.com/ -Framework Bootstrap - strona www w PHP Bootstrap to środowisko służące do budowania responsywnynych stron internetowych, pozwala na bardzo dokładne dopasowanie do stron własnych potrzeb. Zawiera 12-kolumnową siatkę, zarówno w wersji ze stałą jak i z automatyczną szerokością. Posiada bogaty pakiet UI - począwszy od typografii,poprzez formularze, tabele, po nawigacje i ikonki. Całość dopełnia kolekcja skryptów JS pozwalająca na obsługę animacji ekranu. System operacyjny: Komputer Raspberry Pi działa pod kontrolą systemu operacyjnego Raspbian. Baza danych: Baza danych wykorzystana w projekcie to MySQL w wersji 5.5.41. Baza ta służy do rejestracji wszystkich zdarzeń. Pozwala na długoterminową rejestrację temperatury, napięć i prądów w całym systemie. Zapis danych realizowany jest za pomocą skryptów powłoki systemu (Bash) uruchamianych w określonym czasie za pomocą systemowego narzędzia Cron. Dane z bazy pozwalają na późniejsze tworzenie wykresów poszczególnych parametrów na stronie www. Sporą częścia projektu jest strona www - aplikacja internetowa, stąd wykorzystanie bazy MySQL i frameworka PHP, nie chciałbym się rozpisywać na temat samego pisania i uruchamiania strony www bo ta może mieć dowolną formę. Z poziomu systemu wbudowanego chodzi o to, że strona www wywołuje funkcję javascriptową frameworka webiopi, np. po wciśnięciu przycisku wywoływana jest funkcja zmiany stanu wejścia z "0" na "1" lub funkcja okresowo sprawdzająca dane z czujnika temperatury. Dzięki wykorzystaniu frameworka korzystamy praktycznie z gotowego rozwiązania które realizuje dwukierunkową komunikację www - raspberry. Uruchomienie systemu - nie jest to poradnik krok po kroku jednak przedstawia gotowy przepis. - Instalacja i podstawowa konfiguracja raspbian - tutaj odsyłam do poradników w internecie - Instalacja fail2ban Ten etap nie jest konieczny jednak ze względu na mnóstwo botów próbujących dostać się do raspberry podłączonego do internetu polecam użycie tego programu. Pozwala on na dodawanie reguł blokujących połączenia z Internetu po ustalonej liczbie nieudanych logowań. Zapobiega to atakom typu brute-force. W pliku konfiguracyjnym pakietu, dostępne są m.in. ustawienia monitorowanego portu, maksymalna liczba nieudanych prób połączenia, czas blokowania danego adresu IP . Ze względu na powtarzające się przypadki uzyskania próby dostępu do komputera ilość możliwych prób dostępu to 3, a czas blokady 30 dni. Ponieżej zrzut ekranu pokazujący adresy IP zablokowane w ciągu zaledwie jednego dnia. Potwierdza to tylko konieczność stosowania tego typu zabezpieczeń, oraz nie używania prostych haseł do tego typu systemów. Oczywiście nie raz zdarzyło się mi zablokować samego siebie - jednak w przypadku fizycznego dostępu do RPI nie stanowi to większego problemu. Po zabezpieczeniu dostępu do komputera, kolejnym krokiem jest instalacja pakietu i2ctool. Jest to pakiet dzięki któremu możliwa jest obsługa i diagnostyka magistrali I2C. Po zainstalowaniu pakietu możemy sprawdzić podłączone urządzenia za pomocą polecenia i2cdetect –y 1. Wyświetli nam ono listę podłączonych urządzeń w formie matrycy adresowej. Adresy wyświetlane są w formie szesnastkowej. Adresy poszczególnych urządzeń konfigurowane są za pomocą odpowiednich połączeń wyprowadzeń na danych modułach. W prezentowanym rozwiązaniu pod adresem 20 znajduje się moduł 8 wejść – wyjść. Adres 40, to układ 16 wyjść PWM. Adres 48 zajmuje przetwornik analogowo – cyfrowy. W celu umożliwienia sterowania magistralą niezbędne jest też dodanie użytkownika do grupy i2c. Po poprawnym zainstalowaniu I2C widoczny jest taki wynik polecenia i2cdetect: Obsługa magistrali 1-wire, nie wymaga instalacji dodatkowego oprogramowania w systemie. Lista podłączonych urządzeń wraz z ich adresami dostępna jest po sprawdzeniu zawartości katalogu systemowego /sys/bus/w1/devices/, wynik polecenia ls dla tego katalogu został przedstawiony na zdjęciu poniżej. Do magistrali zostały podłączone dwa czujniki temperatury DS18B20. Dla najnowszego raspbiana powyższy opis może być trochę przekłamany, ja korzystałem z dystrybucji pobranej w styczniu 2015 roku, ostatnio przy zabawie z raspberry i uzyciu najnowszego systemu konieczne jest dopisanie linijki w pliku konfiguracyjnym. Opisane jest to m.in tutaj: http://osworld.pl/raspberry-pi-obsluga- termomertrow-ds18b20/ Głównym etapem jest instalacja najważniejszego frameworka, pakietu WebIOPi. Instalacja polega na pobraniu spakowanej paczki ze strony autora i uruchomieniu skryptu instalacyjnego. Tutaj żeby nie kopiować internetu również odsyłam na stronę gdzie opisana jest cała instalacja: http://webiopi.trouch.com/INSTALL.html Dostępne sa tam również przykłady dla konkretnych urządzeń oraz dokumentacja pozwalająca zrozumieć zasadę działania. W dalszej części przedstawie fragmenty swoich skryptów, dla konkretnego rozwiązania. Początek etapu instalacji: Po zainstalowaniu pakietu. I wydaniu polecenia startowego /etc/int.d/webiopi start, możemy za pomocą przeglądarki internetowej otworzyć domyślną stronę internetową frameworka WebIOPi. Adres strony to numer IP komputera oraz domyślnie port :8000. Po wpisaniu adresu, strona będzie wymagała uwierzytelnienia w postaci domyślnego hasła. Widok domyślnie hostowanej strony został przedstawiony na zdjęciu poniżej. Są to podstawowe elementy frameworka umożliwiające sprawdzenie jego działania w tym przypadku działania układów wejść -wyjść. Po sprawdzeniu działania podstawowych funkcji frameworka, należy za pomocą pliku konfiguracyjnego określić sposób jego działania. Polega to na dopisaniu wszystkich adresów urządzeń które mają być obsługiwane. W projekcie będą to 3 urządzenia w magistrali i2c, opisane jako adc, mcp oraz pwm. A także 2 urządzenia magistrali 1-wire opisane jako temp1 oraz temp2. Każde ze zdefiniowanych urządzeń prezentuje na stronie diagnostycznej rejestrowane parametry oraz jeżeli jest to możliwe, przyciski do sterowania testowania i zadawania wartości. Na tym etapie możliwe jest dokładne sprawdzenie działania wszystkich podzespołów. Po zakończeniu testów, w pliku konfiguracyjnym należy podać ścieżkę docelowej strony sterującej, oraz dodać aplikację do skryptów startowych systemu. Dokładny opis: http://webiopi.trouch.com/Tutorial_Basis.html Kolejnym krokiem jest instalacja serwera apache wraz z modułami bazy danych mysql potrzebnymi do jej obsługi. Po instalacji wymagane jest stworzenie bazy danych, potrzebnej do rejestracji parametrów z czujników. Instalacja serwera FTP, znacznie ułatwia wymianę plików z komputerem, oraz późniejsze edytowanie skryptów odpowiedzialnych za działanie systemu. W prezentowanym rozwiązaniu został zainstalowany pakiet proftpd. Współpracuje on z programem fail2ban zabezpieczając dodatkowo zawartość przed niepowołanym dostępem. Wszystkie niezbędne pakiety zostały zainstalowane. Za pomocą protkołu FTP została wgrana strona www oraz skrypty sterujące do ścieżki wcześniej ustawionej w pliku konfiguracyjnym WebIOPi. Aplikacja internetowa: Aplikacja internetowa. Aplikacja internetowa w formie strony www została napisana wykorzystując języki HTML, CSS i JavaScript. Wykorzystanie skryptów JavaScript pozwoliło na wyświetlanie i sterowanie parametrami sterownika na stronie bez konieczności jej przeładowywania. Jednym z założeń było stworzenie strony działającej na urządzeniach mobilnych. Zostało to zrealizowane przy pomocy frameworka Bootstrap, który automatycznie dopasowuje jej zawartość do szerokości i proporcji ekranu. Interfejs aplikacji został zaprojektowany w formie prostokątnych kafli, z których każdy odpowiada za inną funkcję. Poniżej został przedstawiony widok strony startowej na komputerze z monitorem o rozdzielczości 1920x1080, oraz telefonu komórkowego o takiej samej rozdzielczości. Pomimo takiej samej rozdzielczości ekranu, strona została odpowiednio powiększona i dopasowana do komfortowego przeglądania jej na telefonie komórkowym. Poszczególne zakładki zostały ukryte w formie rozwijanego menu dostępnego pod jednym przyciskiem (prawy górny róg). Strona składa się z 4 głównych zakładek: monitoring, oświetlenie, diagnostyka oraz ustawienia. Pierwsza zakładka to jednocześnie strona startowa. Wyświetla ona najważniejsze rejestrowane parametry takie jak temperatura w pokoju dziennym, temperatura na zewnątrz, prąd pobierany przez cały obiekt, stan poszczególnych punktów oświetlenia, napięcie zasilania sterownika, oraz stan elementów nadzorujących bezpieczeństwo w obiekcie. Poszczególne kafelki wyświetlają informacje o tych parametrach oraz pozwalają na interakcję w postaci uruchamiania określonych funkcji. W przypadku przekroczenia nominalnej wartości danego parametru, np. temperatury w pokoju dziennym wyższej niż 22 stopnie Celsjusza, kafelek wyświetlający ten parametr zmienia kolor na pomarańczowy. Użytkownik zostaje również powiadomiony o tym fakcie, odtworzeniem informacji „Temperatura w pomieszczeniu jest za wysoka”, za pomocą podłączonych do komputera głośników. Odtwarzaniem dźwięku zajmują się niezależnie pracujące skrypty. Analogiczna sytuacja ma miejsce w przypadku zbyt niskiej wartości temperatury. Kafelek zmienia kolor na niebieski, a użytkownikowi zostaje odtworzony komunikat „Temperatura w pomieszczeniu jest za niska”. Aplikacja internetowa spełnia tylko rolę interfejsu komunikacyjnego z użytkownikiem, nie jest niezbędna do działania całego systemu, jednak pozwala na sterowanie systemem oraz podgląd zarejestrowanych parametrów. Kafelek odpowiedzialny za wyświetlanie temperatury, jest jednocześnie przyciskiem otwierającym okno wykresu, który generowany jest na podstawie ostatnich 200 pomiarów temperatury, rejestrowanych co 15 minut.: Wykres generowany jest za pomocą biblioteki Google Chart API, pozwalającą na dowolną konfigurację wyświetlanych elementów. Po kliknięciu na dany punkt wykresu, w prawym górnym rogu wyświetlana jest szczegółowa informacja o zarejestrowanym parametrze. Wykres jest animowany, pozwala na powiększenie danego fragmentu w celu dokładniejszej analizy, co w przypadku np. pomiaru prądu, umożliwia zlokalizowanie źródła zużycia energii elektrycznej. Poszczególne elementy kodu potrzebne do zrealizowania wykresu to skrypt rejestrujący temperaturę i datę wykonania pomiaru do bazy danych, oraz skrypt generujący wykres, korzystający z biblioteki Google Chart API. Aktualne parametry pobrane ze sterownika wyświetlane są na stronie www za pomocą java skryptu korzystającego z możliwości frameworka WebIOPi. Jako przykład zostanie przedstawiona funkcja odświeżająca wszystkie parametry na stronie startowej z interwałem 500ms. Jej kod jest zaprezentowany poniżej: Kolejną główna kartą aplikacji internetowej jest oświetlenie. Za pomocą tej podstrony możemy sterować wszystkimi punktami oświetleniowymi, oraz monitorować ich stan. W zależności od sprzętowej konfiguracji systemu wyświetlane są tu kafelki odpowiedzialne za włączanie lub wyłącznie oświetlenia, a także sterowanie jego jasnością. Kafelek w prawym dolnym rogu pozwala na włączanie lub wyłączanie wszystkich lamp w pomieszczeniu. Ikona żarówki podświetlona na żółto informuje o zapalonej danej lampie. Wyświetlany stan jest zależny od rzeczywistego stanu wyjścia przypisanego do sterowania danej lampy. Sterowanie fizycznymi przyciskami może odbywać się niezależnie od działania aplikacji internetowej. W przypadku włączenia światła przez użytkownika w pomieszczeniu przy wykorzystaniu fizycznego przełącznika, stan przycisku w aplikacji internetowej również ulegnie zmianie. Ostatnim elementem na stronie jest sterowanie jasnością oświetlenia LED. Odbywa się ono poprzez przesuwany pasek, który zadaje wartość z przedziału 0-100 w zależności od swojej pozycji. Jednocześnie wartość ustawiana jest na przypisanym wyjściu cyfrowym w module PWM, który generuje przebieg prostokątny o wypełnieniu procentowym z przedziału 0-100. Karta „diagnostyka” jest bardzo przydatna w procesie montażu i serwisowania całego systemu. Umożliwia wykonywanie niektórych komend systemu, bezpośrednio z poziomu przeglądarki, pozwala na sprawdzanie stanu i adresów podłączonych do magistral urządzeń, posiada opcje restartu lub wyłączenia systemu, oraz wykonuje testowe odtwarzanie komendy głosowej konieczne w przypadku regulacji nagłośnienia. Ostatnią zakładką jest zakładka „Ustawienia”, która docelowo ma służyć do ustawień wyglądu poszczególnych ekranów, wartości krytycznych dla danych parametrów, oraz włączania i wyłączania poszczególnych funkcji systemu. Programami nadzorującymi pracę systemu są skrypty wykonywane cyklicznie lub na żądanie użytkownika. Skrypty wykonywane cyklicznie w systemie, zostały napisane w jezyku powłoki Bash, zaś skrypty odpowiedzialne za działanie systemu w zależności od stanu poszczególnych urządzeń napisane są w języku Python. Skrypty te wykonują większość zadań całego systemu inteligentnego budynku i są podstawą jego działania. Cykliczne wykonywanie programów zrealizowane jest za pomocą systemowego narzędzia CRON, uruchamia on co 15 minut skrypt odpowiedzialny za pomiar temperatury z czujnika temperatury i zapis jego stanu do bazy danych. Dzięki temu możliwe jest generowanie przebiegów temperatury w aplikacji internetowej. Dla każdego czujnika istnieje osobny skrypt. Kod skryptu przedstawia się następująco: Programy realizujące poszczególne funkcje systemu to skrypty pracujące pod kontrolą frameworka WebIOPi. Pozwalają one na nadzorowanie np. stanu przycisków i w przypadku jego zmiany wykonanie określonej funkcji. Ze względu na możliwość sterowania oświetleniem zarówno z aplikacji internetowej, jak i fizycznych przycisków, pojawił się problem zmienionej pozycji przełącznika światła, w przypadku zgaszenia lampy z poziomu aplikacji internetowej. Przypisanie funkcji światła na stałe do przycisku, uniemożliwiło by sterowanie nim z innych źródeł. Rozwiązaniem tego problemu jest poniższy kod, reagujący tylko na zmianę stanu przycisku i zmieniający stan lampy w zależności od tego czy jest zapalona czy zgaszona. Innym przykładem funkcji systemu są funkcje realizowane poprzez wywołanie danego makra przez użytkownika. Po wciśnięciu przycisku z poziomu przeglądarki wywoływana jest funkcja frameworka, wykonująca dane makro napisane w języku Python. I tak makro „shutdown” wykonuje polecenie systemowe „reboot” po czym zwraca do funkcji wartość „Sterownik: system zostanie wyłączony”, dzięki czemu aplikacja może wyświetlić odpowiedni komunikat. Przykładowe funkcje przedstawia poniższy fragment kodu. Za pomocą opisanych skryptów możliwa jest realizacja dowolnej funkcji żądanej przez użytkownika. W prezentowanym rozwiązaniu zostały zaimplementowane m.in. takie funkcje jak gaszenie światła w całym mieszkaniu za pomocą włącznika przy łóżku, który jednocześnie zapala tylko lampkę nocną. Szybkie przełączenie przycisku przy drzwiach wejściowych wyłączające wszystkie światła, bez konieczności wyłączania wszystkich po kolei. Skrypty powiadamiające użytkownika za pomocą odtwarzanych komunikatów, realizują swoją funkcje tylko w przypadku odpowiedniej pory dnia. Czujnik ruchu niezbędny w skrypcie alarmowym, w przypadku rozbrojonego alarmu załącza z minimalną jasnością oświetlanie LED, umożliwiając dojście do łazienki bez konieczności zapalania świateł. Podwyższony pobór prądu, który w przypadku dłuższego braku ruchu w pomieszczeniu, pozwala na poinformowanie właściciela o włączonym odbiorniku energii elektrycznej. Nie jestem w stanie opisać całego kodu aplikacji - bo jest go sporo, zamieszczam źródła do przejrzenia - które raczej nie pozwolą na bezpośrednie uruchomienie systemu ale dla kogoś korzystającego z opisanych frameworków mogą być przydatne. Na koniec jeszcze film z testów czujnika temperatury. Inteligentna kawalerka.zip
  7. 12 punktów
    Ten artykuł jest tłumaczeniem (za zgodą autora) na język polski artykułu napisanego przez Paula Stoffregena, dostępnego pod adresem: https://www.pjrc.com/how-to-get-tech-help-from-strangers-on-the-internet/. Internetowe fora techniczne mogą być bardzo onieśmielające. Trzy proste zasady mogą znacznie ułatwić ci życie i zwiększyć szansę na uzyskanie pomocy, niezależnie od poziomu twoich umiejętności. Dobre Pierwsze Wrażenie — aby ludzie chcieli ci pomóc, Wyjaśnij Kontekst — aby ludzie zrozumieli czego potrzebujesz, Podaj Szczegóły — aby ludzie mogli ci pomóc, Poziom 1: Aby dostrzegli twój problem, Poziom 2: Aby mogli go powtórzyć. Dobre Pierwsze Wrażenie "Nie ma drugiej szansy na zrobienie pierwszego wrażenia" to ponadczasowe powiedzenie. Obcy ludzie błyskawicznie wyrabiają sobie o tobie opinię zaledwie na podstawie słów, obrazów lub nagrania w twoim komunikacie. Niech te słowa zadziałają! Największy wpływ na ludzką chęć do pomocy ma pokazanie, że sam włożyłeś wysiłek w rozwiązanie problemu. Ale jaki to może być wysiłek jeśli dopiero zaczynasz? Łatwo jest skorzystać z wyszukiwarki internetowej używając słów ze swojego pytania. Wielu ekspertów nie zdaje sobie jednak sprawy jak trudno jest znaleźć zrozumiałą i istotną informację gdy nie zna się właściwej terminologii, lub gdy te same słowa używane są także w niezwiązanych z twoim problemem dziedzinach. Zatem napisanie czego próbowałeś szukać i jakie wyniki są dla ciebie niezrozumiałe lub nie na temat może pomóc doświadczonym ekspertom w zrozumieniu twojej sytuacji. To nie wyniki są tutaj istotne, ale twój osobisty wysiłek. Szczera chęć nauki także zazwyczaj sprawia dobre wrażenie. Nawet parę słów pokaże twoje podejście. Bycie zniecierpliwionym, ale zdecydowanym na naukę na błędach robi dobre wrażenie. Inteligentni ludzie, którzy mogą pomóc, często doceniają szczere i uczciwe postawienie sprawy. Oczywiście jeśli już rozpocząłeś swój projekt i pracujesz nad nim, wspomnij o tym. Albo nawet lepiej, pokaż czego już próbowałeś. Zrzuty ekranu, zdjęcia, a nawet krótkie nagranie mogą doskonale zaprezentować co już zrobiłeś i upiec dwie pieczenie na jednym ogniu, jednocześnie komunikując i robiąc dobre wrażenie. Nawet kilka prostych słów dodanych do pytania, pokazujących że szczerze się starasz i chcesz się uczyć będzie mieć duży wpływ na odpowiedź, jaką otrzymasz. Kontekst Umożliwia Zrozumienie Istoty ludzkie mają niesamowitą umiejętność dogłębnego zrozumienia. Eksperci mogą zastosować swoją ogromną wiedzę do wypracowania twórczych pomysłów rozwiązujących twój problem... pod warunkiem, że będą wiedzieć czego tak naprawdę potrzebujesz. Kluczowe jest wyjaśnienie kontekstu pytania. Co chcesz osiągnąć? Jak twoje pytanie jest z tym związane? Jakie rozwiązanie byłoby dla ciebie idealne? Dlaczego? Kiedy zajmujemy się techniczną stroną zagadnienia, łatwo jest skupić się tylko na bezpośrednim problemie. Pamiętaj, że przyjaźni ludzie o ogromnej wiedzy i doświadczeniu regularnie czytają fora tylko dlatego, że lubią pomagać. Kiedy piszesz swoje pytanie, nie zapomnij opisać kontekstu. To może zmienić odpowiedź z technicznie poprawnej ale całkowicie bezużytecznej informacji, na rzeczywiście przydatną radę. Diabeł Tkwi w Szczegółach Współczesne zagadnienia techniczne często zawierają oszałamiającą ilość szczegółów. Ile informacji powinno zwierać twoje pytanie? Zanim je wyślesz, zastanów się nad tymi dwoma kwestiami: Czy czytelnik będzie mógł zrozumieć istotę twojego problemu? Czy będzie mógł go odtworzyć? Łatwo jest sobie zakpić "był jakiś błąd, ale zamknąłem go bez czytania", ale bądźmy poważni, minimalny poziom detali pozwoli czytelnikom zrozumieć problem. Zrzut ekranu lub dokładna kopia tekstu błędu, plus dokładna informacja o użytym oprogramowaniu, wersjach, sprzęcie oraz przedsięwziętych kroków to absolutna podstawa umożliwiająca czytelnikowi w ogóle dostrzec problem tak, jak ty go widzisz. W idealnej sytuacji ludzie czytający twoje pytanie powinni móc powtórzyć twój problem. Taki poziom szczegółowości nie zawsze jest praktyczny, ale jeśli dostarczysz wystarczająco dużo informacji, to szanse na rozwiązanie problemu znacznie się zwiększają. Pytania na temat programowania powinny zawsze zawierać cały kod źródłowy, a nie tylko wycięte fragmenty. Często problem ukrywa się w subtelnych szczegółach w definicjach zmiennych daleko od właściwego kodu. Doświadczeni programiści wiedzą czego szukać i potrafią dostrzec takie błędy natychmiast, jeśli tylko pokażesz cały swój kod. Nie zapomnij także poinformować jakich dokładnie bibliotek używasz. Zagadnienia dotyczące sprzętu elektronicznego często nie obejdą się bez zdjęć albo szczegółowych schematów połączeń, oraz linków do użytych części, lub ich symboli katalogowych. Nieśmiałość i niechęć do opisywania szczegółów swojego projektu na forum są powszechne. Nie wstydź się! Eksperci czytający forum naprawdę chcą pomóc. Pokaż dość szczegółów, wyjaśnij kontekst i pokaż, że się starasz, a oni z pewnością pomogą. Częste Błędy Fora nie zawsze działają idealnie. Powyższe trzy kroki najczęściej zadziałają, ale należy też pamiętać o kilku powtarzających się błędach: Zbyt Wiele Zgadywania Rozwiązywanie technicznych problemów polega na obserwacji i dedukowaniu przyczyn. Całkowicie normalne jest, że kiedy jesteśmy na tym skupieniu, to piszemy w zasadzie tylko na podejrzewanych przez nas przyczynach, a zapominamy opisać zaobserwowane efekty. Krótka przerwa przed napisaniem pytania często tutaj pomaga. Kiedy piszesz, staraj się myśleć z punktu widzenia czytelnika. Czy na pewno prosisz o pomoc w problemie, czy tylko chcesz, aby potwierdzili to co sam już odgadłeś? Z drugiej strony, opisanie jak doszedłeś do swoich wniosków może pomóc uniknąć niepotrzebnego powtarzania tego samego toku rozumowania. Nie ma idealnej metody. Po prostu pamiętaj, że zbytnie skupianie się na wnioskach może powstrzymać ludzi od pomocy. Dawanie Upustu Frustracji Szczerze mówiąc niektóre problemy są bardzo trudne i niesłychanie irytujące. Kiedy jesteś zły, dawanie upustu emocjom jest całkowicie naturalne. Zanim wyślesz wiadomość na forum, robiąc tak istotne pierwsze wrażenie, przeczytaj ją przynajmniej raz. Pewien poziom emocji jest normalny i może nawet pomocny. Pokazuje, że naprawdę się starasz. Ale strzeż się częstego błędu, gdy twoja wiadomość jest odbierana jako narzekanie a nie prośba o pomoc. Brak Odpowiedzi Nawet w idealnej sytuacji czasem nie dostaniesz odpowiedzi. To może rozczarować i przygnębić. Postaraj nie dać się ponieść tym emocjom i nie domagać się odpowiedzi. Jest lepszy sposób. Wysiłek jest istotny. Jeśli minęły całe dnie lub tygodnie od wysłania pierwszej wiadomości, to zapewne w tym czasie włożyłeś w swój projekt trochę więcej pracy? Nawet jeśli bezowocny, ten wysiłek jest czymś, czym warto się podzielić, aby przyciągnąć ludzi. Zdjęcia lub kod, albo inne efekty twojej pracy mogą bardzo pomóc. Czasem bardzo trudne i szczegółowe pytania pozostają bez odpowiedzi, bo po prostu nikt jej nie zna. Albo nikt nie jest pewien. W tej sytuacji dobrze jest zapytać o opinie albo sugestie w którym kierunku szukać odpowiedzi, aby usprawnić rozmowę. Ponownie, pokazanie wysiłku jest kluczowym czynnikiem zachęcającym ludzi do pomocy. Większość forów zniechęca lub nawet zabrania wysyłania wielokrotnie tej samej wiadomości czy "krospostowania". To prawie nigdy nie działa. Eksperci, którzy regularnie czytają fora — ludzie najbardziej skłonni do pomocy — na pewno to zauważą. Masz tylko jedną szansę na zrobienie dobrego wrażenia. Natomiast po dłuższym czasie bez odpowiedzi, ponowienie pytania, najlepiej z linkiem do poprzedniej wiadomości i dodatkowym wyjaśnieniem, nie musi być źle odebrane. Nierzetelni Uczniowie Na każdym forum zdarzają się leniwi uczniowie domagający się odrobienie za nich pracy domowej. Eksperci czytający fora regularnie są zalewani takimi marnymi pytaniami. Nie chcesz, aby twoje pytanie zostało potraktowane jak spam i zignorowane. Jeśli twój projekt jest robiony w ramach zajęć, to najlepiej jest szczerze się do tego przyznać (oraz do terminów) i upewnić się, że widać jednak twój własny wkład. Rzetelny wysiłek i szczera chęć nauki wyróżniają dobrych uczniów. Zastrzeżone Projekty Kiedy nie możesz podzielić się kodem źródłowym albo innymi szczegółami technicznymi, pomoc na forum rzadko będzie dobra. Zazwyczaj musisz poświęcić dodatkową pracę aby wydzielić problematyczny fragment z reszty projektu, aby móc go opublikować. Jeśli tego nie zrobisz i po prosty spytasz "czy ktoś spotkał się kiedyś z takim problemem", to traktujesz ludzi jak wyszukiwarkę internetową. Czasem może się udać, ale naprawdę trudno jest zgadywać na ślepo rozwiązania trudnych technicznych problemów. Jeśli twój pracodawca lub organizacja kategorycznie nie zgadza się na publikowanie kodu lub szczegółów, niezależnie jak drobnych, być może zamiast szukać darmowej pomocy na forum powinieneś użyć komercyjnych produktów, które zapewniają kontraktowo wsparcie, albo zatrudnić eksperta z firmy konsultingowej. Kiedy Otrzymasz Odpowiedź Najlepszym sposobem na wyrażenie wdzięczności jest wskazanie osoby, która udzieliła poprawnej odpowiedzi. Wielu ekspertów poświęca niezliczone darmowe godziny swojego czasu pomagając obcym na forach tylko dlatego, że lubią pomagać. Bycie docenionym jest miłą nagrodą. Kiedy twój problem jest rozwiązany, pamiętaj, że wielu innych ludzi trafi do tego wątku szukając rozwiązania podobnego problemu jeszcze wiele lat później. Najlepiej więc jest napisać na koniec krótką wiadomość podsumowującą poprawne rozwiązanie. Jeśli pytałeś w wielu miejscach, to wypada teraz odwiedzić każde z nich i podlinkować do wiadomości z odpowiedzią. O Tym Artykule (i Autorze) Przez ostatnie 6 lat odpowiedziałem 18620 razy na forum PJRC i nawet więcej na innych forach. Udało nam się w tym czasie stworzyć całkiem dobrą społeczność i pomóc w projektach wielu tysiącom ludzi. Obserwowałem i próbowałem się nauczyć co działa i jak możemy dokonać ulepszeń. Oczywiste stało się, że wielu ludzi potrzebuje nieco wsparcia w zadawaniu dobrych pytań. Najbardziej liczą się tu nie technikalia, ale subtelne czynniki ludzkie. Mam nadzieję, że wszystkie fora techniczne się poprawią. Proszę podzielcie się tym artykułem. — Paul Stoffregen
  8. 12 punktów
    KTR-X1 8x8 To pojazd zdalnie sterowany do wykonywania zadań w bardzo trudnym terenie, charakteryzuje się prostotą konstrukcji, niskim środkiem ciężkości oraz uniwersalnością. KTR-X1 8x8 zbudowany jest z dwóch sekcji połączonych przegubem, dzięki temu każda sekcja jest niezależna, dodatkowo ruchome wahacze dają ogromne możliwości w pokonywaniu przeszkód w terenie. Pojazd obojętnie w jakim terenie się porusza,oraz jak stoi, zawsze ma doskonałą przyczepność na wszystkie 8 kół. Dzięki temu że KTR-X1 jest hybrydą można bez obaw wybrać się na dalekie wyprawy gdyż prądu nam nie zabraknie. Specyfikacja: Podwozie: rama stalowa z profila zamkniętego 30x30x1,5 spawana Wahacze: profil zamknięty 40x80x2 wspawane bloki łożyskowe Osie: stal utwardzana Poszycie: blacha aluminiowa 0.8mm wzmacniania kątownikami Przegub: blacha stalowa 10mm plus łożyska Przeniesienie napędu: przekładna łańcuchowa przełożenie1,5:1 Napęd: 4 silniki 24V / 450W każdy (moc znamionowa) 123 RPM Układ skrętu: pompa hydrauliczna 120 bar plus dwa siłowniki Sterownik silnika: Sabertooth 4x32A Sterownik pompy: Sabertooth 2x32A Zasilanie: Akumulatory kwasowe 12V 40Ah 2x Układ ładowania: silnik spalinowy 200c OHV plus alternator 28V 55A Koła: 145/70/6 Pilot sterowania: HK-T6 Oświetlenie: led 2x9W przód, 2x2W tył Układ chłodzenia: 2x wentylator 4800 RPM Przyłącza: szybkozłącze montażowe plus gniazdo zasilania Spalanie: 0,5-1,2l/mth Masa: 140Kg Prędkość max: 8km/h Wymiary: szer 90cm, dłu 192cm, wys 68cm, prześwit 27cm Dalsze plany: Pług do śniegu obrotowy (zrobiony) Zamiatarka (dalszy etap) Kosiarka (dalszy etap)
  9. 11 punktów
    Witam serdecznie Pragnę zaprezentować mój zdalnie sterowany pojazd o wdzięcznej nazwie Przebiegły Tyran Podstępności Konstrukcja powstawała przez 5 miesięcy. Zbudowana jest głównie ze stali i aluminium. Pojazd waży 24 kg i ma 60 cm długości. Prędkość maksymalna to około 15-20 km/h. Konstrukcja nie posiada skrętnej osi, skręcanie odbywa się jak w czołgu Każde koło jest napędzane własnym silnikiem z przekładnią z chińskiej wkrętarki. Każdy silnik pobiera bodajże 26A maksymalnie i działa na 12V. Za zasilanie odpowiadają dwa żelowe akumulatory 12V po 10Ah każdy, a także 8 litowo-jonowych akumulatorów 3,7V - 2200 mAh. Silniki są sterowane z Arduino Pro Mini przez mostki zbudowane z tranzystorów mosfet. Na pokładzie znajduje się także drugie Arduino gdyż zabrakło mi pinów na wszystkie podzespoły Komunikacje z trzecim Arduino będącym pilotem zapewniają moduły radiowe HC-11 433MHz. Oświetlenie przednie zapewniają 2 LEDY 1-watowe, 2 LEDY 3-watowe i 2 halogeny po 35W. Tylne oświetlenie to cztery 1-watowe czerwone LEDY. Na dachu znajduję się odsuwana klapa zasłaniająca wyrzutnie rakiet. Otwiera się dzięki gwintowanemu prętowi zamocowanemu na osi silnika i nakrętce przytwierdzonej do ruchomej części. Wyrzutnia rakiet zmienia kąt strzału dzięki serwu. Mieści 6 pocisków. Odpalanie działa tak że każda rakieta ma wokół lontu owinięty cienki drucik, dwa końce drucika są połączone z akumulatorem poprzez przekaźnik. Gdy przełącze przekaźnik, prąd przepala drucik i następuje zapłon. Każda rakieta ma swój własny przekaźnik więc mogą być odpalane niezależnie.
  10. 10 punktów
    Już słyszę głosy: O, staremu ethanakowi coś się chyba pokręciło... Post jest o jakimś Kedrigernie w dziale DIY - a na zdjęciu mamy coś przypominającego robota z dumnym napisem "Ciapek"... Spieszę z wyjaśnieniami. To nie pomyłka. Post jest na temat serwera mowy Kedrigern, a Ciapek to żaden robot. Po prostu dość trudno zrobić zdjęcie programu, poza tym wypadałoby raczej pokazać ów program w działaniu - a ten wymaga jednak czegoś co będzie gadać (czyli jakiejś bardziej fikuśnej obudowy na głośnik). A ponieważ ostatnio zapatrzyłem się w rysunki Daniela Mroza... cóż, Ciapek z ludzkimi dłońmi, stopami i uszkami wyszedł tak jak wyszedł Zacznę możę od opisu elektroniki (jako że jest to najprostsze, a użytkownik może sobie ją skomponować z zupełnie innych elementów). Sercem całego układu jest Raspberry Pi. Można zastosować dowolny model (chociaż ze starymi, krótkimi GPIO mogą być lekkie problemy), ja użyłem w swoim egzemplarzu Raspberry Pi Zero W. Oprócz tego potzebny jest jakikolwiek układ odtwarzania dźwięku. "Duże" (pełnpowymiarowe) malinki jak popularny 3B+ mają już wyprowadzone wyjście audio, potrzebny jest tylko jakiś niewielki wzmacniacz. Dla wersji Zero potrzebny jest jednak układ zewnętrzny. Prawdopodobnie doskonale spisałby się opisywany ostatnio moduł z wyjściem audio do Raspberry Pi Zero, ja zastosowałem jednak moduł i2s. Jest on dość wygodny w użyciu jako że zawiera w sobie wzmacniacz mono o całkiem sporej (do 3 W) mocy, poza tym początkujący elektronicy nie muszą się martwić o jakieś dziwne masy audio, filtrowane zasilania i tym podobne dziwactwa interesujące tylko "analogowców" - moduł podłącza się pięcioma przewodami do malinki, z drugiej strony dwoma do głośnika i już gra Ponieważ nasz "robocik" musi potrafić poruszać ustami, zastosowałem najprostsze (i najprawdopodobniej najtańsze) rozwiązanie - czyli matrycę LED 8x8 ze sterownikiem, na której rysowane będą kształty ust. Od razu uprzedzę pytanie: owszem, próbowałem zrobić bardziej skomplikowany mechanizm używający serw. Niestety - oprócz trudności mechanicznych (te są do przezwyciężenia) natrafiłem na rzecz, której nie da się przeskoczyć: prędkość serwa. Typowe serwo potrzebuje 0.1 sekundy na przekręcenie orczyka o 60° - a nawet zakładając, że owe 60° wystarczy (w co osobiście wątpię), jest to co najmniej dwa razy za wolno (przy czym owe "dwa" mogłoby się w rzeczywistych układach rozrosnąć do trzech czy czterech). Będę jeszcze próbować rozwiązania z solenoidami - jeśli mi się uda to opublikuję wyniki. Ale może w międzyczasie ktoś inny napisze moduł "solenoid"? Zresztą - chciałem, aby każdy mógł sobie w domu wypróbować Kedrigerna ponosząc jak najmniejsze koszty, a opisywany układ można (mając RPi z wyjściem audio) zmontować kosztem klikunastu złotych (matryca) bez żadnych płytek - po prostu łącząc matrycę przewodami z GPIO malinki. Jako głośnika użyłem leżącego gdzieś w szufladzie zakurzonego głośniczka od starego telefonu z sekretarką, pasować jednak będzie dowolny pod warunkiem dopasowania mocy głośnika do posiadanego wzmacniacza. I to cała wielce skomplikowana elektronika. Jak widać na zdjęciu - nie ma tam nic skomplikowanego. Przejdę więc do opisu programu. Kilka lat temu udało mi się zmusić Mbrolę do w miarę prawidłowego gadania po polsku (do tego stopnia, że można ją było wykorzystać np. do tworzenia audiobooków). System TTS Milena (tak się nazywa ten "zmuszacz" do Mbroli - czyli bardziej fachowo NLP) bardzo dobrze sprawdził się na pecetowym Linuksie, wersja na Windows była raczej ciekawostką ale również działała - postanowiłem więc przystosować ją do malinki. Po przezwyciężeniu pewnych trudności z kompilacją (np. "char" dla architerktury Intel to w GCC domyślnie signed, w ARM z jakichś przyczyn unsigned) okazało się, że co prawda Milena działa, ale "rozruch" ma straszliwie powolny. Nic dziwnego - pliki tekstowe słowników wymowy i translacji fonetycznej muszą być kompilowane przy załadowaniu programu, a malinka ze swoją wolniutką kartą pamięci i nieszczególnie silnym procesorkiem potrzebuje zbyt dużo czasu, zanim wydobędzie z siebie jakieś zdanie. Postanowiłem więc zrobić inaczej: serwer wczytuje wszystkie pliki raz przy starcie systemu, a prosty program klienta przekazuje mu tylko treść komunikatów. Takie rozwiązanie ma również inne zalety: uruchomiony na sockecie TCP serwer może być na zupełnie innej fizycznej maszynie niż klient. I w ten sposób powstał program Kedrigern (nazwany na cześć pewnego czarodzieja, który postanowił odczarować księżniczkę z zaklęcia odbierającego głos). Jak mi to wyszło - oceńcie sami. Oto filmik ukazujący Kedrigerna w działaniu: Nie będę tu rozpisywał się o wszystkich zasadach działania i możliwościach Kedrigerna i Mileny (to w końcu ma byc post na forum a nie książka z dokumentacją), zacznę więc od instalacji Kedrigerna na malince. Wszystkie konieczne komponenty (z wyjątkiem głosu pl1) są w załączonym pliku tgz. Rozpakujmy go w dowolnym katalogu (np. w głównym katalogu użytkownika malinki) i instalujemy mbrolę wraz z polskim głosem: sudo dpkg -i mbrola3.0.1h_armhf.deb sudo apt install mbrola-pl1 Teraz możemy zainstalować Milenę. I tu uwaga: jeśli ktoś miał starszą wersję Mileny niż 0.2.92 musi ją przeinstalować na tę właśnie wersję - inaczej nie będzie działać moduł ruchu ust Kedrigerna! sudo dpkg -i milena*.deb Po zainstalowaniu wszystkiego powinno działać już polecenie milena_say, czyli musimy wypróbować: milena_say dzień dobry kolego I znów uwaga: jeśli wyjściem audio jest HDMI, polecenie może nie działać prawidłowo! Należy spróbować dodać parametr -d opóżniający generację mowy do czasu "załapania" HDMI, czyli najprościej: milena_say -d 2000 dzień dobry kolego Niestety, przy użyciu wyjścia HDMI mogą pojawić się problemy z późniejszym działaniem Kedrigerna, ale po pierwsze nie jest to miejsce na omawianie problemów z audio, po drugie wcale nie czuję się mistrzem w tym zakresie i prawdopodobnie ktoś tu wie lepiej ode mnie jak tym problemom zaradzić. W każdym razie mając uruchomiona Milenę i Mbrolę możemy przystąpić do instalacji Kedrigerna. Zaczynamy od instalacji serwera, czyli sudo dpkg -i kedrigern_0.2.0-1_armhf.deb Jeśli mamy podłąćzoną matrycę LED (8x8, MAX7219) możemy użyć jej jako wyświetlacz ust: sudo dpkg -i kedrigern-matrix_0.2.0-1_armhf.deb No i oczywiście coś co pozwoli nam korzystać z serwera, czyli: sudo dpkg -i libkedrigern_0.1.2-1_armhf.deb Teraz możemy sprawdzić, co potrafi nasz serwer: kedrigern -h lub (jeśli mamy zainstalowany moduł matrix) kedrigern -M matrix -h W odpowiedzi dostaniemy wykaz opcji, z którymi możemy uruchomić serwer. Aby je przetestować, należy otworzyć drugi terminal; w pierwszym uruchamiamy serwer poleceniem "kedrigern" z różnymi opcjami, w drugim testujemy poleceniem kdr-say. Po ustaleniu opcji należy zedytować plik /etc/default/kedrigern i w nim ustawić domyślne parametry. Po przetestowaniu poleceniem kedrigern -C /etc/default/kedrigern możemy już uruchomić nasz serwer w tle: sudo systemctl start kedrigern Jeśli chcemy, aby serwer startował od razu przy starcie systemu, należy wydać polecenie: sudo systemctl enable kedrigern Do komunikacji z serwerem służą polecenia kdr-say, kdr-stop i kdr-speaking. Moduł matrix pozwala na wyświetlanie ust zsynchronizowane z głosem syntezatora. Oto przykładowe obrazy ust dla różnych fonemów: Fonem A Fonem I Fonem O Fonem U Fonemy M, P i B Wybrałem do pokazania kilka najbardziej charakterystycznych kształtów. Jeśli komuś nie odpowiadają stworzone przeze mnie kształty może w prosty sposób dorobić własne lub poprawić moje na bazie pliku /usr/share/kedrigern/demo.shape i podłączyć go do Kedrigerna, np. za pomocą opcji "-m matrix:shape" lub wprowadzając odpowiednie zmiany w pliku konfiguracyjnym. Protokół komunikacyjny jest bardzo prosty. Nie wnikając w szczegóły - załączony moduł w Pythonie (działa w wersji 2 i 3 Pythona) pozwala na sterowanie serwerem, a jednocześnie stanowi przykład sposobu komunikacji. I to wszystko... A nie, nie wszystko. Bo zaraz ktoś powie że to tylko zabawka, że komu potrzebne gadające roboty... Przede wszystkim: Kedrigern może generować komunikaty diagnostyczne w czasie testowania/programowania robota. Jakie to ma znacze nie nie muszę chyba mówić nikomu, kto choć raz ustawiał np. regulatory silników czy zakres ruchu serw w warunkach polowych. Poza robotyką może być bardzo dobrym rozwiązaniem do urządzeń typu headless - ja np. stosuję podobne (poprzednika Kedrigerna) rozwiązanie do obsługi sterownika pieca CO (podanie np. godzin nieobecności w mieszkaniu) czy jako wygodnego interfejsu do wpisywania wyników pomiaru ciśnienia krwi i poziomu cukru z małej przenośnej klawiaturki. A to już nie są zabawki A w ogóle przypominam, że Roomba też gada (tyle że Ciapek ładniej) Zdaję sobie sprawę z tego, że opis jest bardzo pobieżny. Z chęcią odpowiem na wszystkie pytania - o ile kogoś to będzie interesować... W każdym razie wypróbowanie Kedrigerna nawet bez modułu ust posiadacza RPi z wyjściem audio nic nie kosztuje, a może się przyda? Kody źródłowe Mileny i Kedrigerna są dostępne na stronie http://milena.polip.com A, i ostatnie wyjaśnienie: Ciapek to mały troll, wychowanek czarodzieja Kedrigerna w książce Johna Morressy'ego "Głos dla księżniczki". Nawet trochę podobny Przy okazji: @Treker, czemu pliki zip są cacy a tgz są be? kedrigern.zip pykedrigern.zip
  11. 10 punktów
    Cześć, chciałbym przedstawić Wam mojego robota Celem pracy było wykonanie zdalnie sterowanego robota dobrze radzącego sobie w terenie, który wysyła obraz i dane z czujników do operatora. Budowa: Pierwszy etap budowy to projekt CAD w programie Autodesk Inventor 2015. Zawieszenie to uproszczona wersja systemu jezdnego rocker - bogie. (Link do wiki z zasadą działania wikipedia ) Zawieszenie: Praca zawieszenia: Silniki to Pololu 37Dx57L mm z przełożeniem 100:1, do tego adaptery na hex 12mm, i koła z Wild thumpera. Na maszcie znajduje się dedykowany moduł kamery do Raspberry Pi, wraz z reflektorami + dwa serwa Tower Pro do sterowania ruchem masztu. Oprócz tego z boku jest mała skrzyneczka w której znajduje się buzzer oraz czujnik wilgotności i temperatury DHT22: Całość projektu wygląda następująco, z tyłu widać zamontowaną antenę: Konstrukcja została wykonana tak jak przewidywał projekt, oprócz tego robot został oklejony folią moro, co dodało mu powagi ;D Praca zawieszenia: Elektronika: - Raspberry Pi - główny komputer sterujący, - Moduł rozszerzeń podłączany do portów GPIO (zawiera przetwornik ADC MCP3008, zegar RTC, cyfrowy kompas HMC588L i układ Darlingtona ULN2803A) - Silnikami sterują elektroniczne regulatory prędkości używane w samochodach RC, - Generator PWM Adafruit - generuje sygnał do serwomechanizmów i ESC, - Nano router TP-Link TL-WR703N do zapewnienia łączności WiFi, został lekko zmodyfikowany - przylutowałem złącze RPSMA do podłączenia zewnętrznej anteny. - Akumulatory to pakiety ogniw 18650, zostały stworzone dwa - jeden 2S do zasilana elektroniki, drugi 3S do zasilania serwomechanizmów i silników. Półka elektroniki: Pozostałe elementy: Oprogramowanie: Aplikacja sterująca na PC wykorzystuje bibliotekę QT, i SFML (obsługa pada Xbox), na robocie całość została napisana w Pythonie Okno wygląda następująco, jak widać znajdują się tam wszystkie odczyty z czujników, sterowanie światłami, buzzerem, oraz przycisk uruchamiający kamerę: Strumieniowanie video: Aby zapewnić jak najmniejsze opóźnienie i obraz HD został użyty Gstreammer. Starałem się wszystko opisać w dużym skrócie, jak macie jakieś pytania to piszcie
  12. 10 punktów
    The way I see it, if you're gonna build a line follower, why not do it with some style? W ten oto wyjątkowy dzień OCT 21 2015, chciałbym zaprezentować swoją najnowszą konstrukcję, na początek jednak please excuse the crudity of this model. I didn't have time to build it to scale or paint it - a tak na poważnie brak czasu i masa obowiązków a zostało trochę rzeczy do dopieszczenia m.in wydruki 3d. Tak więc dokumentacja, porządne zdjęcia, i filmy pokazujące pełne możliwości tej konstrukcji zostaną opublikowane w późniejszym terminie - a robot na bank pojawi się na Robotic Arenie we Wrocławiu (możliwe że gdzieś wcześniej). ELEKTRONIKA Projekt składa się z czterech płytek PCB zaprojektowanych w CadSoft EAGLE. Płyta główna - grubość 1mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. Sercem robota jest 32 bitowy PIC32MX270F512H, do jego dyspozycji jest również osobny 1mb pamięci NVSRAM z podtrzymaniem bateryjnym Microchip 23LCV1024 (np. zapamiętanie trasy w trakcie zmiany głównej baterii). Napięcie 5.9V zapewnia przetwornica ST1S10PHR, natomiast za 3.3V odpowiada Microchip MCP1826S. Do sterowania silnikami - Toshiba 6612FNG. Na płytce znajdują się również trzy rejestry przesuwne NXP 74HC595 do sterowania efektami świetlnymi. 3 przyciski w tym dwa maleństwa do obsługi tablicy. Możliwość odbioru IR przez Vishay TSOP34836. P-MOSFET IRLML6401 do ochrony wejścia przed odwrotną polaryzacją. Większość drobnicy w obudowach 0603 Płytka czujników - grubość 0.8mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. KTIR0711S oraz miejsce pod SHARP GP2Y0D340K. Płytka enkodera i płytka silnika - grubość 0.8mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. Płytka przeznaczona do podłączenia enkoderów AS5040 - z prawie lustrzanym odbiciem z obu stron w celu obsługi dwóch kół robota z wykorzystaniem jednego wykonania PCB dla obydwóch stron. Razem z płytką silników imituje "kominy" filmowego De Loreana. FLUX CAPACITOR - 12 białych diod LED (wlutowanych do góry padami) odpowiada za efekt pracy kondensatora strumienia. RADIATION METER - dzielnik rezystorowy + ADC -> pomarańczowa dioda 0603 zaczyna migać w momencie spadku napięcia baterii. TIME CIRCUITS - tablica z niezależnym podświetleniem każdej daty - dwoma przyciskami ustawiamy na niej przed jazdą tryb w jakim ma robot pracować. NEONY - 3 wytrawione na głównej płytce + cztery 3mm diody do podświetlenia rurek wychodzących od płyty głównej do płytki enkoderów. OUTATIME - element obowiązkowy MR FUSION - na spodzie - bateria, góra skrywa w sobie malutki włącznik. ŚWIATŁA niezależne sterowanie światłami: przednimi (osobno wewnętrzne osobno zewnętrzne) oraz tylnymi (stopy, migacze, wsteczny). LICZNIK - when this baby hits 88cm/s you gona see some serious shit - wskazuje prędkość, przy 88cm/s odpalają się neony. MECHANIKA CDN... __________ Komentarz dodany przez: Treker Ale kolega punktów w regulaminie działu złamał... Ciężko wyliczyć wszystkie... Jednak w związku z oryginalnością konstrukcji poprawiłem niezbędne minimum i opublikowałem
  13. 10 punktów
    Witam, chciałbym zaprezentować manipulatora mojej konstrukcji. Głównymi założeniami projektu były: - Zbudowanie manipulatora o 6 stopniach swobody, - minimalne rozmiary z zachowaniem jak największej funkcjonalności oraz podobieństw do tych pracujących w przemyśle, - zachowanie szeroko pojętej estetyki. Na sam początek przeprowadziłem parę prób co do sterowania silnikami dc (bo takie planowałem użyć (cena)). Następnie zabrałem się za rysowanie modelu CAD robota, który powstał w programie Catia V5. Dodatkowo przeprowadziłem symulację ruchów manipulatora, co zapobiegło kilku błędom. Jako materiały do budowy brałem pod uwagę PMMA, stal oraz aluminium. Są one stosunkowo łatwe w obróbce i ogólno dostępne. Ważnym kryterium przy projektowaniu było zapewnienia odpowiedniej sztywności całej konstrukcji oraz fakt że w czasie projektowania i budowania nie miałem dostępu do frezarki/drukarki 3D, przez co całość musiała być tak zaprojektowana abym był w stanie wykonać wszystkie części samodzielnie. Robot jest łożyskowany w osiach 1-4. Końcowo ze stali wykonane są osie obrotowe 1-2, 2-3, 3-4. Z aluminium platforma obrotowa, mocowanie ramienia i kilka mniejszych części. Elementy z PMMA to większość konstrukcji głównie z płyt 2 i 4 mm wycinane na waterjet'cie. Kształtowanie polegało na podgrzewaniu hot air’em, następnie nadawaniu kształtu na kancie biurka. O samym "procesie" wytwarzania części mógłbym dużo pisać bo praktycznie wszystko robiłem samodzielnie w mniej lub bardziej elegancki sposób, dlatego najlepiej będzie odpowiadać na Wasze pytania (jeśli będą). Sam chwytak powstał trochę później, głównie dlatego że nie był niezbędny do funkcjonowania manipulatora a trzeba było ciąć koszty. Model chwytaka też powstał w Cati (razem z symulacją ruchu) i w tym przypadku został on wydrukowany z racji bardzo małych kształtów. Problematyczne okazało się znalezienie odpowiednio małego napędu, przekładni, łożysk. W środku znajdują się dwa przyciski krańcowe, a sterowanie jest siłowe. Za ruch ramion odpowiadają silniki DC z przekładniami. Silniki osi 1 -3 pochodzą z rozmontowanych drukarek, a przekładnie do nich otrzymałem z demontażu serw modelarskich. W osiach 4-6 zamontowane są silniki z dedykowaną przekładnią. Jako sprzężenie zwrotne wykorzystałem enkodery optyczne które też pochodzą z drukarek. Rozdzielczość dla każdej z osi wynosi >=0.1. Pracę silników kontrolują regulatory PID. Nad pracą robota czuwa ATxmega 128A1. Początkowo w ramach testów układ powstawał na płytce uniwersalnej. Ostatecznie płytkę PCB zaprojektowałem w AD13 w ramach pracy przejściowej. Może nie będę rozpisywał się za bardzo nad elektroniką w załącznikach jest schemat. Elektronika zasilana jest z 12 VDC w środku znajdują się 2 przetwornice na 3,3V oraz 5V (na schemacie sa LM317). Kod napisany w środowisku eclipse w C. Pisanie oprogramowania było najbardziej czasochłoną czynnością. Standardowo DMA, ADC, PWM, WDT, USART, PLL, Timery. Całość zamknięta jest w metalowej obudowie gdzie na górnej części umieszczony jest grzybek, wyświetlacz, 4 przyciski, oraz 3 diody. Na przednim panelu jest złącze DB15 służy do programowania, oraz podłączania dodatkowych urządzeń (wyprowadzono z niego kilka pinów uC i wszystkie napięcia). Następnie mamy złącze zasilania 12V DC, złącze usb służące do podłączenia do PC, bezpiecznik oraz włącznik zasilania. Po przeciwnej stornie znajdują się złącza do podłączenia manipulatora. Przez robota przeprowadzonych zostało 38 przewodów z czego 34 są używane reszta to nadmiar. Od spodu sterownika znajduje się wentylator. Obecnie mamy 3 możliwości kontrolowania manipulatora. - Poprzez PC (RS-232), powstała dedykowana aplikacja napisana w Lazarusie (Delphi). Umożliwia ona pełną kontrolę manipulatora, pomiar prądu silników, wymuszeń skokowych, tworzenie sekwencji ruchowych, modyfikację wzmocnień regulatorów PID, kalibrację itp. - Poprzez Smartphonea, powstała aplikacja na androida napisana w AppInventorze. Umożliwia kontrolę każdej osi manipulatora, kalibrację, odtwarzanie sekwencji oraz wysyłanie pojedynczych rozkazów. - Poprzez przyciski znajdujące się na obudowie sterownika. Dają takie możliwości jak sterowanie każdą z osi oraz wybór sterowania tzn. Aby sterować poprzez inne źródło najpierw musimy włączyć tą opcję na sterowniku. Jakby nie było ciężko napisać że projekt jest "skończony". W dużym stopniu udało mi się zbliżyć do manipulatora przemysłowego, a co za tym idzie można na nim testować przeróżne algorytmy, sposoby sterowania, kinematyke itp. z tą różnicą że nie kosztuje 100 tys. pln, a całe oprogramowanie jest "wymienne". Jeśli chodzi o koszty to: - elektronika ok. 700 zł, - mechanika ok. 1550 zł (650 zł to chwytak). Suma: 2250 zł (to ta optymistyczna wersja Smile). jak na przeciętnego studenta to dość sporo jak na zabawkę Smile. Pewnie pojawi się pytanie "kraj taki piękny, unia europejska, manna z nieba nie da się otrzymać jakiegoś dofinansowania na tego typu projekty ?." - Niestety nie, lub po prostu zbyt dużo papierków, chodzenia, proszenia i czekania. Jak napisałem we wstępie, manipulator stał się podstawą mojej pracy magisterskiej, która polegała na zbudowaniu systemu sterowania z wykorzystaniem logiki rozmytej. Końcowym efektem było zmniejszenie przeregulowań napędów o 64,5% w stosunku do tradycyjnego regulatora PID. Praca w załączniku. Podsumowując projekt uważam za udany nauczył mnie wielu rzeczy z różnych dziedzin nauki i to jest najcenniejsze, ale jak to przy takich projektach bywa teraz zrobiło by się pewne rzeczy inaczej/lepiej. Chciałbym też podziękować za pomoc kilku pracownikom wydziału MT oraz Elektrycznego. NIE JESTEM AUTOREM PLATFORMY JEZDEJ Kilka filmików z działania manipulatora, miłego oglądania. Zachęcam do zadawania pytań. Manipulator - code C.zip Manipulator - App lazarus.zip Schematic.PDF PDM_MarekSliz.pdf
  14. 9 punktów
    Witam wszystkich, od mojego ostatniego postu tutaj minęło sporo czasu ale wcale nie porzuciłem robotyki. Jak wszyscy wiemy życie po studiach zaczyna zjadać coraz więcej czasu. Prawie 4 lata temu wrzuciłem tutaj post z moją konstrukcją robota typu delta (Delta Robot). Mam wrażenie, że bardzo fajnie się przyjął i tamta konstrukcja (jak wspominałem 4 lata temu) była prototypem, na którym zaczynałem się uczyć. Cztery lata rozwoju nie tylko mnie ale też dostępnej technologii jak np. druk 3D i mocniejsze mikrokontrolery niż poczciwa Atmega pozwoliły mi rozwinąć skrzydła. Ale przechodząc do meritum, przedstawiam moją następną wersję robota typu delta: Robot składa się w tym momencie z: ramienia, taśmociągu, systemu wizyjnego. systemu generującego podciśnienie 1.Mechanika Do zrobienia tego robota wykorzystałem tyle części z poprzedniej konstrukcji ile się dało. Ale ze względu na postęp techniki i moje większe możliwości finansowe większość przeprojektowałem w SolidWorksie i wydrukowałem na własnej drukarce 3D. Ramiona zamontowane są na podwójnie łożyskowanym wale, który napędzany jest poprzez pasek zębaty, a ten z kolei przez silnik krokowy z zamontowanym 12bitowym enkoderem. Taśmociąg także sam zrobiłem z profilu aluminiowego z Allegro oraz silnika DC z przekładnią. Pas kupiłem z profesjonalnej firmy na zamówienie. Może to brzmi groźnie i drogo ale tak nie jest. Pas kosztował 110 zł brutto. robot posiada 4 osie, dokładnie tak jak poprzednia konstrukcja. 2. Elektronika Najważniejszym układem scalonym jest mikrokontroler TEENSY 3.6 (link) zajmuje się: sterowaniem silnikami krokowymi, obsługą enkoderów silników jak i taśmociągu, komunikacją z komputerem, zapisem programów, punktów oraz wszelkich ustawień na karcie SD Jest to kontroler kompatybilny z bibliotekami Arduino i szczerze dla całego projektu zbawienne było to, że miałem gotowe biblioteki dla wielu rzeczy i nie musiałem się uczyć tego procka wraz z wszystkimi rejestrami, algorytmami zapisu na kartę SD, protokołu SPI oraz obsługi wielu peryferii jak sterowniki silników krokowych (o tym za chwilę) oraz np. ekranu LCD. Mogłem się skupić na moim celu czyli aplikacji, która ma spełniać moje założenia. Dodatkowo w kontrolerze, a także w ramieniu znajdują się: Teensy 3.2 - obsługa ESTOP, IO (wejść/wyjść), obsługa LCD oraz pomost w komunikacji pomiędzy głównym prockiem, a Arduino w ramieniu, Arduino Nano - obsługa PID taśmociągu, sterowanie serwochwytakiem ( kontroler Pololu Maestro), sterowanie pompą podciśnienia oraz elektrozaworem, Arduino Nano - komunikacja z komputerem poprzez zTCP/IP Silniki wyposażone są w enkodery absolutne AMS AS5045, które dostałem za darmo. Robot wyposażony jest w 4 wejścia oraz 4 wyjścia 24V (standard przemysłowy). W celu testowania czy wszystko dobrze działa zrobiłem dodatkowo prosty panel z 4 diodami oraz 4 przyciskami do testowania czy wszystko dobrze działa. Silniki sterowane są poprzez sterownik silników krokowych AMIS-30543 (link), który pozwala na konfiguracje poprzez magistralę SPI, a także na sterowanie z mikrokrokiem x32, które to sterowanie tutaj wykorzystuję. Dodatkowo jak widać na zdjęciach zaprojektowałem oraz zmontowałem (po dostaniu od Satlandu) płytki, które pozwoliły wszystko spiąć ze sobą. Nie będę wrzucał schematu PCB, bo nie jest to nic interesującego. 3. System wizyjny Robot skalibrowany został z systemem wizyjnym OpenMV (link). Kamera została zaprogramowa w języku Python i jej zadaniem jest w zadanym czasie (komunikat wysłany po uart) zrobić zdjecie i zliczyć bloby o odpowiedniej wielkości. Kamera wurzyca po porcie uart dane do mikrokontrolera głównego w postaci NUMER/X/Y/KĄT/ już we współrzędnych robota. Po dostaniu danych do tablicy punktu dodawana jest aktualna pozycja taśmociągu. Dzięki temu robot jest w stanie trafić w detal podczas ruchu taśmy. 4. System sterowania Całość oparta jest na matematyce, mikrokontroler oblicza zadanie proste oraz odwrotne kinematyki (dla pozycji oraz prędkości). W przeciwieństwie do starej konstrukcji układ sterowania naprawdę bierze pod uwagę pozycję oraz prędkość, dzięki temu robot porusza się bardzo płynnie oraz może zachować określoną prędkość liniową punktu TCP (Tool Central Point). Algorytmy pozwalając na poruszanie się w trybach: JOINT - ruch obliczany jest tak, aby każda oś zakończyła pracę w tym samym czasie, LINEAR - ruch lionowy punktu TCP z określoną prędkością liniową, TOOL - ruch liniowy ale zgodny z układem współrzędnych narzędzia CONV - tryb ruchu liniowego z załączonym śledzeniem taśmy, Cały program posiada w tym momencie jakieś 6 tys linijek kodu i pozwala na pracę w trybie automatycznym jak i ręcznym robota. Całość jest napisana w języku C/C++. 5.Program na PC Program napisany w C# w środowisku VisualStudio. Pozwala na: załączenie silników (przekaźnik odcinający na linii 24V), Zwolnienie napędów (enable na sterowniku krokowców) ułatwia ręczne uczenie punktów, Resetowanie błędów, Sterowanie robotem w trybie ręcznym, Uczenie punktów, Edycję ręczną zapisanym punktów na robocie, ustawienie układu TOOL oraz pozycji domowej robota, pisanie prostych programów w skryptowym języku podobnym do BASICA (jestem w trakcie prac) uruchamianie programów w trybie automatycznym, deklarowanie konkretnych działań pod wejścia oraz wyjścia np. cykl start na wejściu 1 podgląd pozycji robota, podgląd IO robota, sterowanie taśmociągiem, zapisywanie oraz sczytywanie ustawień robota oraz punktów z/do pliku na PC po połączeniu z robotem automatyczne sczytanie ustawień oraz punktów z karty SD w kontrolerze. 6.Filmiki Wiem, że to tylko krótki post na temat tego robota i w temacie dla zainteresowanych jest znacznie więcej do opowiedzenia dlatego jak ktoś ma jakieś pytania to zapraszam do komentarzy oraz wiadomości
  15. 9 punktów
    Od momentu poznania ESP8266 bardzo spodobał mi się ten układ. Gdy skończyłem robić pierwszy projekt oparty na tym układzie od razu zacząłem wymyślać kolejny. Dzisiaj chciałbym Wam przedstawić sterownik oświetlenia. Współpracuje on ze zwykłym włącznikiem świecznikowym i mieści się w puszce fi60, dzięki czemu (nad każdym włącznikiem światła mam puszkę fi70) w puszcze fi70 zostaje jeszcze sporo miejsca na kable. Po zaprojektowaniu płytki w programie Eagle zleciłem wyprodukowanie jej firmie jlcpcb. Wszystko trwało tydzień (zamawiałem również inne płytki dlatego tyle to trwało ). Płytki wysłali w piątek po południu czasu lokalnego a w poniedziałek płaciłem już vat u kuriera z DHL . Płytki wyglądają bardzo dobrze (sami możecie ocenić jakość produktu ) Po odebraniu płytek zacząłem wszystko składać w całość. ESP8266 12F zostało wykorzystane jako "mózg" płytki. Jako zasilacz służy Hi-Link HLK-PM01 230V na 5V. Za załączenie napięcia odpowiedzialne są dwa przekaźniki z cewką na 5V. Dodatkowo do każdego przekaźnika dołożyłem diodę prostowniczą. ESP jest zasilane napięciem 3.3v przez co musiałem zastosować LDO. Dodatkowo na wejściu fazy do układu zamontowałem bezpiecznik firmy bel fuse. Żeby esp mogło załączać przekaźnik musiałem wykorzystać tranzystor bc817 w wersji smd. Do tego potrzebowałem jedno złącze ark raster 5mm podwójne, oraz dwa złącza ark raster 5mm potrójne. Całość po zlutowaniu i umieszczeniu w puszcze fi60 wygląda następująco: Teraz przyszła kolej na oprogramowanie. Zdecydowałem się zrobić prostą stronę konfiguracyjną na której możemy: zmienić hasło do urządzenia zmienić dane serwera mqtt (sterowanie z każdego miejsca na świecie ) zmienić przyłączenie do sieci wi-fi zobaczyć jak długo pracuje nasz układ wybrać ilość podpiętych włączników (jedno albo dwa) Całość jest również sterowana z telefonu z systemem android. Teraz przymierzam się do zrobienia wersji v2 tego sterownika, chcę by był oparty na triakach i optotriakach (z tego co wyliczyłem to żarówka led o mocy 15W pobiera tylko 60mA a świeci jak zwykła żarówka 120W) oraz będzie posiadała wsparcie dla dotykowych podświetlanych włączników (moduły httm oraz panele marki weilak, wszystko mam tylko projekt został ) Jestem bardzo ciekaw Waszych opinii, dajcie znać w komentarzach co myślicie mo jej konstrukcji
  16. 9 punktów
    Już na samym początku prosiłem o to, aby darować sobie zgryźliwości. Jeszcze raz ponawiam moją prośbę i obiecuję od teraz usuwać wszelkie posty, które będą miały nawet jedno złośliwe zdanie. Niezależnie od tego czy autorem będzie nowa osoba, czy użytkownik, który ma na koncie 100 tysięcy postów - każdego obowiązują takie same zasady. To, że opisywany projekt jest częściowo reklamą tego projektu jest chyba oczywiste - wystarczy poświęcić kilka sekund i obejrzeć filmy, które są w pierwszym poście. Nie przypominam sobie, aby gdzieś był zakaz publikacji tego typu opisów. Nie jest to produkcja masowa, nie widzę więc powodu, aby od razu "rzucać" się na autora i krytykować za wszystko co możliwe. Czym taki projekt różni się od innych DIY, w których autorzy nie podają dokładnej instrukcji budowy i nie dzielą się projektami? Moim zdaniem niczym. Ten projekt wypada nawet lepiej, bo jak ktoś będzie bardzo chciał to sobie chociaż może kupić takie urządzenie. Prawie nikt nie zadał konkretnych pytań technicznych, pojawiały się tylko różne uwagi "byle udowodnić, że projekt jest zły". Autor próbował Wam wszystko wyjaśnić, wstawiał zdjęcia i filmy, a dla Was nadal jest źle. Rozumiem, że komuś projekt może się nie podobać, wystarczy raz wyrazić swoje zdanie lub zignorować temat. Jak widać po głosach czytelników, raportach oraz otrzymanych przeze mnie wiadomościach jest sporo osób, którym ten projekt się zwyczajnie podoba. Proszę więc wszystkich krytyków, aby wzięli pod uwagę, że nie każdy musi się z Wami zgadzać, niektórym taki projekt się podoba i tyle. Nie musicie na siłę wszystkich przekonywać, że jest źle i atakować ciągle autora. Projekt ten zaakceptowałem świadomie i widziałem, że jest to częściowo reklama. Uznałem jednak, że projekt jest ciekawy, nie było u nas opisu takiej maszynki. Liczyłem więc, że takie DIY może być dla wielu osób ciekawą inspiracją. Autor nie jest pierwszą osobą na świecie, która zrobiła takie urządzenie. W Internecie jest sporo maszynek do ręcznej produkcji filamentu. Jak ktoś będzie chciał to wykona urządzenie samodzielnie. To czy jest sens sprzedawać taka maszynkę to już zweryfikuje rynek - jak będą klienci to będzie sens, a jak nie będzie zainteresowanych to trudno, przynajmniej ktoś próbował. Dziwie się osobom, które poświęcają tyle czasu na pisanie krytyki i szukanie zaczepek. Ciężko mi uwierzyć, że liczą one na merytoryczną dyskusje. Nie macie ciekawszych zajęć od krytykowania projektów? Jeśli macie gorszy dzień lub nadmiar energii to proponuje skupić się na chwaleniu DIY, które według Was są ciekawe. Sprawdźcie listę opisanych projektów, znajdźcie coś ciekawego i napiszcie autorowi, że robi dobrą robotę. Nie widzę wielu postów, które chwaliłyby ciekawe DIY - tak ciężko napisać komuś dobre słowo? Jeszcze raz apeluję o ograniczenia zgryźliwość, a wszystkim będzie przyjemniej czytać posty i więcej osób będzie chętnie brało udział w dyskusjach. Zachęcam również osoby, które nie zgadzają się z takimi złośliwościami, aby wyrażały to jakoś publicznie (np. przez posty lub reakcje). Oczywiście doceniam raporty i PW kierowane do mnie, ale może jednak byłoby dobrze, aby autorzy takich wiadomości widzieli, że to "nie są tylko moje wymysły", a jest wiele osób, którym taki ton dyskusji zwyczajnie nie odpowiada.
  17. 9 punktów
    Cześć! Powoli zauważam, że roboty tego typu zaczynają wymierać i odchodząc na lf-ową "emeryturkę" chciałbym zostawić jakiś ślad po swoim projekcie. Choć na zawodach nigdy nie szczędzę informacji na temat swojego robota i chętnie dzielę się wiedzą oraz doświadczeniem w temacie, to mam wrażenie, że ilość lepszych robotów w konkurencji nie zwiększa się, a nawet spada. Na zawodach starzy bywalce ścigają się między sobą, a młodzi pewnie zniechęcają się do konkurencji, ze względu na wysoki próg wejścia do walki o nagrody. Cukiereczek - LineFollower bez turbiny (Nazwa nawiązuje do mojej poprzedniej konstrukcji - Candy). Jest to robot, którego zbudowałem w ramach pracy przejściowej magisterskiej między styczniem a marcem 2018r. Debiutował na zawodach Robomaticon 2018 w Warszawie, gdzie zajął 3 miejsce, zaraz za Candy (zabrakło czasu na napisanie sensownego programu). Później rozwijane było oprogramowanie, które zostało tematem pracy dyplomowej. Wydaje mi się, że jest to obecnie najszybszy robot w swojej kategorii w Polsce, aczkolwiek scena LF od 2018r. mocno się uszczupliła - być może o potencjalnie szybszą konstrukcję. Główne cechy: 12 czujników linii Mikrokontroler STM32 F7 IMU: żyroskop + akcelerometr RGB Lidar ToF USB karta µSD Bluetooth 4.2 Własny mostek H Enkodery magnetyczne 1. Konstrukcja mechaniczna Wydaje mi się, że kształtem przypomina robota Fuzzy, którym swego czasu mocno się inspirowałem przy robocie Candy. Mam nadzieję, że nikt tutaj nie uzna robota za bezpośrednią kopię - kształt jest zdecydowanie inny, podyktowany konkretnymi założeniami i doświadczeniami z poprzednich konstrukcji. Podwozie stanowią 2 moduły PCB: płytki głównej oraz płytki z czujnikami linii, połączone ze sobą taśmą FFC i usztywnione węglową listewką modelarską. Ślizg przedniej listewki zapewniają 2 ścięte łby nylonowych śrubek, z doklejoną podkładką teflonową. Z tyłu robota doklejony jest wheelie bar, w postaci kawałka listewki węglowej ze śrubką oraz teflonem. Wielokrotnie przerobiony temat - gdyby nie podpórka, robot wywracałby się do góry dołem oraz podskakiwał na każdym zakręcie. Napęd: 2 silniki szczotkowe Pololu HPCB 10:1 z obustronnym wałem, na który nałożono magnes 6x2.5 do enkodera magnetycznego. Koła to felgi wydrukowane na drukarce 3D z oponami Mini- Z. Nie dają takiej przyczepności jak poliuretan, ale nie udało mi się dobrać lepszych kół przy samodzielnym odlewaniu. Silniki zostały odrobinę podniesione podkładkami z PCB o grubości 1mm oraz kauczukiem tłumiącym wibracje. Do ich montażu wykorzystałem standardowe, plastikowe mocowania Pololu. Waga konstrukcji to 55.5g (66g z akumulatorem). Nie była priorytetem. 2. Elektronika Wszystkie płytki PCB zostały wykonane w firmie Techno Service z Gdańska. Płytka główna oraz płytka z czujnikami to płytki 4-warstwowe, pozostałe: płytki enkoderów oraz płytka IMU, 2-warstwowe. Schemat oraz layout stworzyłem w programie Altium Designer. Robot może być zasilany z akumulatora li-po 2-4S (6-17V) lub bezpośrednio z USB (bez możliwości uruchomienia silników). Oprócz pomiaru napięcia wejściowego, dodatkowo wstawiono układ pomiaru prądu pobieranego przez robota. Robot startuje obecnie z akumulatorami 2S, 180mAh, 50C. Sekcję zasilania (oprócz sekcji silnikowej) stanowi przetwornica 5V 1A, oraz układy LDO na napięcie 3.3V (osobne dla MCU, sekcji analogowej oraz czujnika IMU). Na płytce czujników znalazło się 12 transoptorów KTIR0711S. Są gęsto ułożone w jednakowych odstępach tworząc delikatny łuk. Zdecydowano się na proste rozwiązanie hardware'owe, dające równomierne odczyty z trasy. Przekombinowany układ czujników mógłby powodować dodatkowe komplikacje (różne odczyty na odsuniętych czujnikach, wpływ nierówności trasy - odległości sensorów od podłoża), więc wszelkie wykrywania dziwnych elementów na trasie realizowane są software'owo. Moduł IMU został zamocowany na padzie kauczukowym tłumiącym wibracje. Użyto sensora Invensense ICM-20602. Jak widać na zdj. poniżej, bardzo poważnie potraktowałem kwestię wibracji, które mają spory wpływ na odczyty. Wykorzystany czujnik posiada wysoką czułość i jest wrażliwy na wibracje i naprężenia. Sensor posiada dedykowaną linię zasilania z oddzielnego LDO o wysokim PSRR. Mostki H zbudowano na układach przekształtnikowych TI DRV8703 oraz tranzystorach N-FET: Toshiba TPWR8503NL. Taki układ mimo, że skonstruowany mocno na wyrost, pozwala na dowolne wysterowanie silnika, w tym zmianę kierunku obrotu bez żadnych dodatkowych opóźnień. Poprzednio stosowane mostki, popularne TB6612 wymagały łączenia kanałów i stosowania opóźnień. Wydajność takiego mostka szacuję na ok. 10A ciągłego prądu (z prądem chwilowym sięgającym +100A), sensownie byłoby lepiej dopasować mostek do wykorzystanych silników, jednak ze względu brak czasu na testowanie i chęć zamknięcia projektu w jednej rewizji PCB, postawiłem na "zero kompromisów". Dodatkowym założeniem była chęć ewentualnej zmiany silników na mocniejsze. Enkodery to AS5047P zamontowane na pionowych płytkach PCB. Podłączone zostały magistralą SPI. Dokonują pomiaru kąta absolutnego, z rozdzielczością 14 bitów. Uwzględniając przekładnię mechaniczną, można uzyskać ponad 160 tysięcy jednostek na obrót koła. Mikrokontroler zastosowany w projekcie to STM32F722 w LQFP64. MCU taktowany jest z częstotliwością 216MHz. Wszystkie piny procesora zostały wykorzystane. Posiada bardzo duży zasób obliczeniowy, znacznie większy od F1, dzięki czemu algorytmy sterujące mogą być skomplikowane i nie trzeba rezygnować z obliczeń na floatach. Karta µSD podłączona została pod SDMMC, na 4-bitowej szynie SDIO. Czujnik odległości to ST VL53L1X, laserowy czujnik Time of Flight, podłączony pod magistralę I2C. Został umieszczony na mocowaniu silnika, w celu uniknięcia dodatkowej bezwładności na listewce robota. Posiada spory zasięg, więc utrata długości z listewki nie jest problemem. Niestety czujnik domyślnie posiada spory field of view, który można odrobinę zmniejszyć tracąc również na zasięgu. Mam z tym czujnikiem sporo problemów. Na zawodach w Rzeszowie wyłapywał patyczki znaków drogowych postawionych przy trasie (inni zawodnicy nie mieli z nimi problemu) oraz bardzo często zdarza mi się, że silnik potrafi zawiesić czujnik podczas przejazdu. Rozwiązania w tej formie nie polecam. 3. Oprogramowanie Przy prowadzeniu projektu wspomagałem się programem CubeMX, a kod pisany był w środowisku Atollic TrueStudio. Poza bibliotekami CubeHAL, z których korzystam, całość własnego kodu została napisana w języku C++. Kod został podzielony na klasy, często wykorzystując przy tym mechanizm dziedziczenia. Użycie C++ pozwoliło wygodnie operować kodem, którego fragmenty wykorzystuję również w innych swoich projektach. Zrezygnowano z wykorzystania RTOSa (FreeRTOS w tym przypadku), ze względu na spory koszt samego OS przy pętlach rzędu 10kHz. STM serii F7 posiada wystarczająco dużo timerów, aby poszczególne zadania podzielić w niezależne pętle z własnym priorytetem. Do obsługi czujników linii, wykorzystano "tylko" 1 przetwornik ADC. Łączenie kilku przetworników w celu uzyskania szybszych pomiarów uznałem za bezcelowe, gdyż prawdopodobnie i tak musiałbym wyzwalać pomiary timerem, aby nadążyć z przetwarzaniem pomiarów. Obecnie pomiary wykonują się z częstotliwością ok. 56kHz i każda próbka brana jest pod uwagę podczas przejazdu. Pozycja linii wyznaczana jest w prosty sposób, przy pomocy średniej z wag przypisanych do każdego czujnika. Wagi czujników są u mnie odrobinę nieliniowe. Osobno rozpatrywane są "przypadki specjalne", gdy pod czujnikami brakuje linii itp. Osobny przetwornik wykorzystano do pomiaru napięcia i prądu. Liczona jest także zużyta pojemność baterii. Pętla sterowania silnikami z regulatorami PID wykonuje się z częstotliwością 8kHz. Nastawy zostały dobrane po części w Matlabie, później dostrojone empirycznie. Pętla żyroskopu również wykonuje się z częstotliwością 8kHz, taktowana jest przerwaniem dataready czujnika. Żyroskop wykorzystuję obecnie do omijania przeszkód oraz w odometrii. Główna pętla - podążania za linią wykonuje się z częstotliwością 400Hz. Sterowanie odbywa się poprzez typowy regulator PD, którego nastawy dobrane zostały metodą prób i błędów, bazując również na poprzedniej konstrukcji - przyspieszony proces. 4. Dodatki Sygnalizacja RGB - Zamiast niezależnych diod LED, wykorzystałem 4 diody WS2812B, które mogłem podłączyć do 1 pinu mikrokontrolera (a zużyłem wszystkie). Na diodach sygnalizowany są stany poszczególnych elementów robota, np. kalibracji żyroskopu, stanu baterii, stanu załączenia silników czy błędu regulatora linii. Interfejs USB - Jedyne złącze użytkowe w robocie. Jako, że interfejs SWD programowania wyprowadziłem w postaci padów do lutowania, "codzienne" programowanie robota odbywało się przez interfejs USB w trybie DFU. Napisany został kod umożliwiający przejście mikrokontrolera do wewnętrznego bootloadera, a następnie wgranie nowego programu. USB służył także do debugowania poprzez port COM. Karta µSD do logowania danych podczas przejazdu. Logowanie odbywa się w tle, w czasie wolnym procesora. Dane zbieram z częstotliwością ~1kHz i zapisuję binarnie w pliku (system FAT32). Logi dostarczyły mi sporo informacji "ukrytych" w robocie i przydały się w pracy magisterskiej. Poniżej przykładowe wykresy dla poboru energii, sterowania, czy utworzonej mapy trasy z uwzględnieniem omijania przeszkody. Aplikacja na smartfon pod moduł BT 4.2. Stosując moduł inny niż HC-05, zmuszony byłem stworzyć własną aplikację smartfonową do zmiany nastaw robota oraz zdalnego startu. 5. Osiągnięcia: 1 miejsce, LineFollower bez turbiny, Robomaticon 2019 w Warszawie , 9 marca 2019 1 miejsce, LineFollower Standard, XI Robotic Arena – Wrocław, 12 stycznia 2019 1 miejsce, LineFollower Enhanc3D, XI Robotic Arena – Wrocław, 12 stycznia 2019 1 miejsce, LineFollower Standard, Bałtyckie Bitwy Robotów w Gdańsku, 26-27 maja 2018 3 miejsce, LineFollower 3D, Bałtyckie Bitwy Robotów w Gdańsku, 26-27 maja 2018 1 miejsce, LineFollower Standard, Zawody ROBO~motion w Rzeszowie, 19 maja 2018 3 miejsce, LineFollower bez turbiny, Robomaticon 2018 w Warszawie, 3 marca 2018 Poniżej kilka filmów:
  18. 9 punktów
    1) Prolog Cześć, dzisiaj opiszę wam mój projekt inżynierski w którym budowałem model autonomicznego pojazdu. W ramach pracy dyplomowej zaprojektowałem uproszczony model autonomicznego pojazdu. Model przystosowany jest do poruszania się w prostym środowisku testowym, symulującym prawdziwe otoczenie. Mój model wyposażony jest w kamerę, pozwalającą na pozyskiwanie informacji o otoczeniu. Obraz z kamery jest źródłem danych dla zaimplementowanej sieci neuronowej, która odpowiada za podejmowanie decyzji o kierunku przemieszczania się pojazdu. Całość pracy zawiera opis poszczególnych etapów tworzenia modelu, projektowanie architektury, implementacje oraz uczenie jednokierunkowych sieci neuronowych do prawidłowego działania. W projekcie użyłem Raspberry Pi, w którym została zaimplementowana sieć neuronowa stworzona w języku Python oraz Arduino odpowiedzialne za sterowanie podzespołami. Rozwiązanie zaproponowane w pracy opiera się szeregu transformacji obrazu za pomocą biblioteki OpenCV w celu ekstrakcji cech tak, aby sieć neuronowa otrzymywała tylko najistotniejsze informacje na podstawie których podejmie decyzje. 2) Wykorzystane elementy: Raspberry Pi B+ (chociaż lepsza była by Raspberry Pi 3b+) Raspberry Pi Cam 8Mpx Lego 42037 Lego Motor M Serwomechanizm SG90 (wymagało modyfikacji) Arduino UNO Rev3 Konwerter poziomów logicznych 2x18650 z rozbiórki laptopów + koszyk L298N - dwukanałowy sterownik silników - moduł 12V/2A 3) Przebieg Prac Praca nie determinowała typu modelu jaki zostanie opisany w pracy a jej głównym celem miało być czy implementacja w prosty sposób funkcji takich jak jazda na wprost, po łuku, skręt czy poruszanie się po okręgu jest możliwa do implementacji wykorzystując sieci neuronowe i wiedzę wyniesioną z toku studiów. W Pierwszej kolejności zrobiłem małe rozeznanie co do możliwości jakie mogłem wybrać i z grubsza można było je podzielić na 2 rodzaje: a) fizyczne - do których zaliczamy np przerobienie realnie istniejącego samochodu osobowego lub modelu pojazdu zdalnie sterowanego RC lub inne tego typu konstrukcje: b) software-owe - w skład których wchodzą takie propozycje jak: dedykowane symulatory, gry komputerowe (symulujemy wtedy klawisze które normalnie naciska gracz) lub własnoręcznie napisane programy do tego celu, np napisane w matlabie lub specjalna "gra" wykorzystana w tym celu. W moim przypadku realizowałem to w pojedynkę i ograniczały mnie dwa aspekty takie jak czas wykonania, koszt który musiał bym ponieść, oraz zasób wiedzy jaki trzeba było by do tego użyć dlatego musiałem znaleźć swojego rodzaju złoty środek którym był fizyczny model (bardziej namacalny) w pomniejszeniu czyli Model RC, ale ze nie posiadam żadnego modelu RC to wykorzystałem zestaw Lego 40237. 4) Hardware Podstawą pojazdu jest już wcześniej wspomniany zestaw Lego 42037 który posiada pewne braki i w tym rozdziale należało zabawkę z lego dostosować do potrzeb projektu. Głównym problemem był brak napędu oraz zdalnego sterowania, o ile z napędem na tylną oś poradziłem sobie bardzo szybko (były już w modelu półosie, dyferencjał i wał) i wystarczyło wstawić w odpowiednie miejsce kilka klocków i silnik Lego M to z układem kierowniczym trzeba było więcej się nagimnastykować. Aby przenie koła wprawić "w ruch" trzeba było znaleźć miejsce na serwomechanizm + zintegrować go z istniejącym układem kierowniczym, dodatkowym problemem był fakt że standardowe serwo ma "wyjście" na orczyk/ wieloklin) al układ kierowniczy lego był zakończony Axlem. Nie chciałem też ingerować i niszczyć klocków dlatego wykonałem nieinwazyjny adapter i skleiłem klejem na gorąco odpowiednio docięty orczyk z klockami które miały otwór na axle. W ten oto sposób nasza podstawa ma wyprowadzone 2 zestawy przewodów - jeden do Silnika napędowego a drugi do serwomechanizmu połączonego z układem napędowym. 5) Elektronika Teraz czas na elektronikę... która jest bardzo prosta bo w zasadzie sygnały sterujące musimy przesłać do 2 komponentów - silnika oraz serwa. W pierwotnym zamyśle było podłączenie bezpośrednio Raspberry Pi do tych 2 komponentów ale wiedziałem że "nie będzie czasu" na generowanie PWM softwareowo dla serwa + dla silnika napędowego dlatego zostało dołożone Arduino które potrafi to robić sprzętowo i odciąży Raspbery Pi od tego zadania. Zyskałem na tym niewielki wzrost skomplikowania elektroniki i oszczędziłem moc obliczeniową w Raspberry Pi. Z kolei silnik napędowy wymagał zastosowania "jakiegoś" mostka H aby nie upalić Raspberry bo wbrew pozorom Silnki z lego potrafią pobierać znaczącą ilość prądu ( więcej info można znaleźć tutaj ) dlatego wybór padł na wcześniej wymieniony gotowy moduł dwukanałowego (zostały zmostkowane oba kanały) mostka H - wystarczy teraz podać tylko odpowiedni sygnał PWM do mostka H i już mamy możliwość płynnej kontroli nad prędkością modelu. Ostatnim etapem było zestawienie komunikacji po porcie szeregowym Arduino z Raspberry Pi za pomocą portu szeregowego i w tym wypadku. Takie połączenie wymaga zastosowania konwertera poziomów logicznych gdyż Raspberry Pi toleruje tylko 3V3 volta a arduino daje 5V - gdyby tego nie było mogło by dojść do uszkodzenia Rarspberry Pi 6) Software I teraz to co tygryski lubią najbardziej - programowanie i tutaj jest podział na 2 części (ale nie mogę wrzucić tutaj kodów źródłowych) a) Arduino Dla Arduino został napisane proste API (ASCII) sterowane przez raspberry - oferowało zestaw prostych funkcji takich jak: - Ustaw silnik na x PWM (zakres 0-255) - Ustaw serwo na x PWM ( 0 - prawo, 90 - prosto, 180 - lewo) - START - Po tej komendzie można było uruchomić pojazd - STOP - powodowała zatrzymanie silnika i ustawienie serwa na 90 stopni (przygotowanie do jazdy na wprost) b) Raspberry Pi Zasada działania tego modelu wykorzystywała sieci neuronowe i nauczanie pod nadzorem nauczyciela ( w skrócie mamy 2 rodzaje uczenia sieci neuronowych - z wykorzystaniem nauczyciela czyli dajemy jakieś dane uczące, potem sprawdzamy na części danych kontrolnych i korygujemy tak długo aż osiągniemy dobre rezultaty i na koniec testujemy na nigdy nie używanych danych, same dane dzielimy w stosunku 4-1-1. Druga opcja to bez nauczyciela i sieć musi nauczyć się sama i jest to o wiele bardziej skomplikowane). Uproszczony schemat działania programu: Aby to działało musimy zaprojektować sieć ( u mnie rozważyłem kilka przypadków) i jest to zależne od ilości wejść i tego co chcemy uzyskać na wyjściu czyli sygnał sterujący w najprostszej wersji może to wykorzystywać kilka neuronów a najbardziej skomplikowane mogą ich mieć dziesiątki tysięcy ( w różnych warstwach) jednak korzystając z Raspbery Pi mamy ograniczą moc obliczeniową i musiałem ułatwić analizę i pracę sieci. Dlatego dokonałem ekstrakcji danych z obrazu i wstępnego przetworzenia w OpenCV gdzie pozyskuje informacje o położeniu linii drogi którą ma podążać: Idąc od lewej - obraz widziany przez kamerę, dalej sektory które obserwujemy aby dokonać analiz "ucieczki linii", trzeci obrazek to binaryzacja i wykrycie gdzie aktualnie znajduje się linia i jak "ucieka" aby można było określić w którą stronę należy skręcić aby jechać prosto. Dzięki temu na wejściu sieci neuronowej podajemy jedynie 2 parametry (położenie lewej i położenie prawej linii) co znacząco ułatwia obliczenia i projekt sieci. Mając te informacje zbieramy dane z przejazdów i zachowania linii podczas konkretnych manewrów np jazda na wprost, po łuku itp. I zapisujemy do pliku - co ważne w tym momencie sterujemy robotem ręcznie i od naszej precyzji sterowania zależeć będa w dużej mierze efekty jakie uzyskamy. Po zebraniu danych możemy przejść dalej. Uczenie sieci: Realizowałem w matlabie i toolboxie z sieciami neuronowymi i tam testowałem jak wyglądają efekty uczenia a następnie eksprtowałem sieć (sieć to tak naprawdę liczby które decydują o "wadze" neuronu poszczególnego) do własnej implementacji w pythonie i testowałem w realu co było pracochłonne. I tak aż do skutku i poprawiałem błędy aż do uzyskania efektu zadowalającego . Na koniec zostały przeprowadzone eksperymenty jak sieć radzi sobie z poszczególnymi testami. 7) Co bym zrobił inaczej W wersji 2.0 lub po prostu gdybym zaczął robić projekt od nowa zmienił bym niestety dosyć dużo widząc jakie braki / niepotrzebne problemy napotkałem na drodze: Rozwiązanie z modelem było dobre - jednak lepiej było do tego celu wykorzystać nie lego a model RC z uwagi na łatwiejszą integrację i o wiele mniejsze luzy w układzie np kierowniczym co generowało duże odchyłki a także dużo większą sztywność konstrukcji i spasowanie. Zastosowanie wydajniejszego SBC np nVidia Jetson lub nawet przenieść to na jakiś iCore desktopowy co zapewni wielokrotnie większą moc obliczeniową Zastosowanie kilku kamer najlepiej czarno białych + doświetlanie IR co pozwoliło by na działanie np o zmroku Wykorzystanie np biblioteki TensorFlow a nie własnej implementacji SN ( skrócenie czasu pisania i eliminiacja ewentualnych błędów z implementacją sieci) Ps. Ciężko opisać wszystkie zagadnienia związane z budową tego modelu w 1-2 kartkach A4 i tak aby nie zanudzić kogoś szczegółami - mam nadzieje że opis nie jest zbyt lakoniczny ale też nie przesadziłem z dokładnością. Może kiedyś powstanie wersja poprawiona to udostępniona szerszy i dokładniejszy opis.
  19. 9 punktów
    Jakiś czas temu w moje ręce trafił dość specyficzny zabytek techniki - układ MCY7880, będący jedynym mikroprocesorem produkowanym seryjnie w Polsce. Element ten był klonem intelowskiego procesora 8080, wytwarzanym przez nieistniejące już przedsiębiorstwo CEMI. Początkowo potraktowałem go jako kolejną elektroniczną ciekawostkę do kolekcji, po jakimś czasie zacząłem się jednak zastanawiać, czy nie będę w stanie wykorzystać go w bardziej konstruktywny sposób. Zacząłem więc gromadzić pozostałe elementy potrzebne do zbudowania prostego systemu mikroprocesorowego, jednocześnie wczytując się w dokumentację i literaturę komputerową z epoki. Właściwa konstrukcja zaczęła powstawać niewiele później. Z uwagi na mocno eksperymentalny charakter przedsięwzięcia zdecydowałem się pominąć etap projektowania PCB i od razu przystąpić do montażu komputera na płytce prototypowej. Najpierw wlutowane zostały podstawki pod układy scalone, potem grubszą srebrzanką poprowadziłem masę i linie zasilające. Należy tutaj nadmienić, że MCY7880 jest dość kłopotliwym procesorem, jeśli chodzi o zasilanie. Nie tylko pobór prądu jest duży jak na obecne standardy, ale także konieczne jest dotarczenie trzech różnych napięć: +12, +5 oraz -5V. Dodatkowo muszą być one podane w odpowiedniej kolejności, niedopełnienie tego obowiązku grozi uszkodzeniem procesora. Oryginalnie systemy mikroprocesorowe na MCY7880 były zasilane z dużych zasilaczy transformatorowych. Była to pierwsza z kilku kwestii, co do których zdecydowałem się na drobny kompromis i zastosowałem nieco uwspółcześnione podejście. I tak napięcie 12V jest generowane przez przetwornicę boost na MC34063A, a -5V jest pobierane z pompy ICL7660. Głowna linia zasilająca o napięciu 5V jest zasilana bezpośrednio ze współczesnego, stabilizowanego zasilacza impulsowego. Po poprowadzeniu masy i zasilania, a także wlutowaniu wszystkich elementów pasywnych, przyszedł czas na najbardziej mozolny etap projektu. Łączenie linii sygnałowych przy pomocy kynaru. Bardzo dużej ilości kynaru. Zajęło mi to kilka wieczorów. O dziwo pomyliłem się tylko raz, zapominając o podciągnięciu jednego z wyprowadzeń EPROM-u do 5V. Po przebadaniu magistrali oscyloskopem i analizatorem stanów logicznych stwierdziłem, że procesor zachowuje się prawidłowo pracując "na luzie" (szyna danych pociągnięta w sposób wymuszający ciągłe wykonywanie instrukcji NOP i zwiększanie licznika instrukcji). Przyszedł więc czas na zaprogramowanie pamięci EPROM. Na potrzeby tego projektu zaopatrzyłem się w chiński programator oraz urządzenie do kasowania tych zabytkowych pamięci. Zapoznałem się także z podstawami asemblera 8080. Pierwszy napisany program służył rzecz jasna do migania diodą podłączoną do znajdującego się na płytce układu 8255. Potem zabrałem się za portowanie TinyBASIC-a, który po jakimś czasie udało mi się odpalić na tym komputerze. Obecnie POLON 7880 może komunikować się ze światem jedynie przez port szeregowy RS232, zrealizowany za pomocą układu 8251 oraz konwertera MAX232. W planach na bliżej nieokreśloną przyszłość jest budowa dodatkowej płytki z interfejsem monitora CRT i klawiatury, a być może także i sterownikiem stacji dyskietek. Pozwoliłoby mi to na uruchomienie systemu operacyjnego CP/M - organizacja pamięci komputera jest do tego przystosowana. Oczywiście najprostszym rozwiązaniem byłoby symulowanie układów I/O za pomocą jakiegoś współczesnego mikrokontrolera, wolałbym jednak wykorzystać w tym celu oryginalne układy scalone z epoki.
  20. 9 punktów
    Przedstawiam mój projekt który zrealizowałem w ostatnim czasie, jest to prosty manipulator osadzony na platformie mobilnej. Założeniem tego projektu było maksymalne uproszczenie konstrukcji i sterowanie jej za pomocą kontrolera od Playstation 3. Całość miała też po naciśnięciu przycisku wykonywać określone funkcje automatycznie. Konstrukcja jest rozwojowa, będzie wyposażona w kamerkę bezprzewodową i dodatkowe czujniki. Konstrukcja to zmaterializowane pomysły z głowy. Przebieg budowy był improwizacją, aczkolwiek niektóre elementy były projektowane. Podwozie zostało zaprojektowane od podstaw, manipulator to zmodyfikowany projekt dostępny w sieci. Podwozie: Manipulator: BUDOWA MECHANICZNA Większość elementów konstrukcyjnych to wydruki 3D. Gąsienice i koła to produkcja LEGO, koła zostały odpowiednio zmodyfikowane przez wklejenie w nie łożysk tocznych. Naciąg gąsienic zrealizowany jest za pomocą podwójnego mimośrodu w tylnych kołach. Wszystkie śruby, nakrętki i podkładki są oczywiście nierdzewne. W każdym połączeniu ruchomym ramienia znajduje się tulejka mosiężna. Nakrętki samochamowalne. ELEKTRONIKA Podwozie napędzane jest przerobionymi serowomechanizmami TowerPro MG995, manipulator wyposażony w TowerPro MG90, tryby metalowe. Do zasilania zastosowano pakiet Litowo-polimerowy 7,4V 1300mAh, na pokładzie znajduje się przetwornica obniżająca odpowiednio napięcie do pracy serw. Mózgiem Jest Arduino UNO z USB host shieldem + Bluetooth. Użytkownik informowany jest o napięciu pakietu i w odpowiednim momencie też ostrzegany sygnałem dźwiękowym za pomocą testera. Na przodzie umieszczono dwie diody led. Podsumowując: - 2x TowerPro MG995 - 3x TowerPro MG90 - Pakiet LiPo 7,4V 1300mAh - Przewornica 3/5A - Arduino UNO - USB Host Shield 2.0 - USB Bluetooth - LiPo tester - 2x LED STEROWANIE Zgodnie z założeniami całość sterowana jest za pomocą Kontrolera od PS3. Lewy analog odpowiada za jazdę, prawy analog obsługuje ramię główne i ramię manipulatora. Przycisk analogowy R2 odpowiedzialny jest za uchwyt. Przycisk R1 powoduje zapamiętanie uścisku, czyli trzyma przedmiot beż konieczności trzymania przycisku R2. Kolejno, przycisk L1 pozwala włączyć oświetlenie LED na przodzie. START uruchamia pętle z programikiem który ma za zadanie podnieść przedmiot oddalony o 15cm przed obrócić się o 180 stopni, położyć przedmiot przed sobą, ponowne naciśnięcie tego przycisku wychodzi z pętli. Czas obrotu dobrany empirycznie. Powtarzalność miejsca uzyskana na poziomie 0,5cm (zadowalająca) SELECT służy do włączenia testu wszystkich serw, ustala określone pozycje, wyjście z pętli po ponownym naciśnięciu przycisku. Podsumowując: - LEWY ANALOG -> jazda - PRAWY ANALOG -> manipulator - R2 -> uchwyt manipulatora - R1 -> zapamiętanie uchwytu - L1 -> włączenie oświetlenia - START -> program wykonujący przenoszenie obiektu (w pętli) - SELECT -> Program testujący pracę serw (w pętli) OPROGRAMOWANIE Program dla płytki mikrokontrolera napisany został w środowisku Arduino IDE, zmodyfikowano w dużym stopniu przykład PS3BT. EFEKTY Zdjęcia: Aktualizacja 29.02 Platforma posiada kamerkę bezprzewodową przekazującą kolorowy obraz i dzwięk. Film: Pierwsze testy sterowania padem: https://www.youtube.com/watch?v=ACa2hxboEXs
  21. 9 punktów
    Cześć! Jako że ostatnio na Forbocie jest opisywanych coraz mniej robotów biorących udział w zawodach postanowiłem opisać swojego robota nanosumo. Sam robot powstał już jakiś czas temu (ok 1,5 roku temu), ale do dzisiaj nieźle mu szło na zawodach i ogólnie jestem całkiem zadowolony z konstrukcji. Wyciągnąłem z niej wiele wniosków i mam nadzieję że kolejna będzie jeszcze lepsza Mechanika : Rama robocika zbudowana jest z malutkich kawałków laminatu, na których ściankach są umieszczone od środka zębatki. Wszystkie koła zebate jak i silniki pochodzą ze znanych 9 gramowych serw. Największym wyzwaniem było upchnięcie dwóch silników na sobie tak by nie podnosiły za mocno całej konstrukcji oraz były dobrze spasowane z zębatkami. Same silniki są przyklejone do siebie oraz do podstawy robota. Koła to przerobione nakrętki mosiężne, w tym momencie nie umiem powiedzieć skąd pochodziły. Wywierciłem w nich otworki i odlałem małe silikonowe oponki. Z przodu robota widoczny jest pług przymocowany na stałe jak i opadający. W sumie nie jestem pewien czy kiedykolwiek pomógł mi podważyć przeciwnika, a czasami sprawiał kłopot z postawieniem bez opadnięcia przed rozpoczęciem walki. Elektronika: Robotem steruje atmega8 taktowana 8mhz z zewnętrznego kwarcu. Ma wgrany bootloader, by oszczędzić pinów na płytce. Oczami są 4 czujniki, z czego jeden jest nieaktywny, gdyż nie miałem miejsca na moduł startowy i musiałem pozbyć się diod ir. Czujniki to, jak w każdej mojej konstrukcji, tsopy i diodki ir smd. Są naprawdę fajne pod względem zasięgu (który da się regulować), jednak zajmują sporo miejsca na pcb. Diodki są sterowane tranzystorami, jednym na parę diod. Mostek to malutki 24 pinowy qfn od freescale - MPC17531. Czujniki linii to ktiry0711s zamocowane na samym dole robota. Moduł startowy postanowiłem umieścić w całości w robocie. Chciałem mieć pewność, że moduł za każdym razem się poprawnie zaprogramuje, a następnie bez problemu wystartuje. Oprócz tego jest trochę drobnicy, nie ma regulatora, wszystko zasilane jest bezpośrednio z li-pola 140 mAh. Program: Zawsze staram się pisać jak najprostsze programy do walczących robotów i tak też było w tym przypadku. W sumie tradycyjnie "wyifowane" warunki na czujniki i poszczególne reakcje silników - nic szczególnego. Pora na osiągnięcia: - 1 miejsce Robomaticon 2015 - 1 miejsce TTR 2015 - 1 miejsce Roboxy 2015 - 2 miejsce Sumochallenge 2015 - 1 miejsce RoboticArena 2015 - 3 miejsce Robomaticon 2016 W tym roku nanoHaker2 dostał się także do ćwierćfinałów Robotchallenge 2016. Robot jest już stary i szykuję powoli nową konstrukcję, w nadziei że w końcu uda się zdobyć podium w Wiedniu I jeszcze na koniec parę zdjęć : Jak znajdę jakieś filmiki z udziałem nanoHakera wrzucę linki. Mam nadzieję, że się podobało i czekam na pytania Pozdrawiam, Piotrek
  22. 9 punktów
    Witam. Przedstawiam kolejną konstrukcję. Kilka lat temu pokazywałem pierwszego robota balansujacego. Dobre oprogramowanie takiej konstrukcji nie jest proste wiec teraz skorzystałem ze znalezionego w sieci projektu pod nazwą B-robot http://www.3ders.org/articles/20131029-b-robot-a-fully-3d-printed-self-balancing-arduino-robot.html Kolega który wcześniej go robił zmodyfikował soft z WIFI na BT, ja dorobiłem tylko jakieś oczy sygnalizujące słabą baterię. Moja konstrukcja względem oryginału nie ma serwa oraz ma wysoko baterię co znacznie podwyższa środek ciężkości. Oryginał znacznie ciekawiej przez nisko umieszczony SC się wychyla. Co do konstrukcji: - rama w całości narysowana i wydrukowana na własnym Reprapie - silniki - krokowe jaki były pod ręką - elektronika - arduino mini + 2xstepstick + mpu6050 - aplikacja stworzona w AppInventorze Kilka fotek Filmik (kręcony na dość grubym dywanie, na parkiecie czy zwykłym dywanie jeździ trochę szybciej i nie kołysze się na postoju): Pozdrawiam Sławek
  23. 8 punktów
    Posiadając dwa futrzaki pojawiła się potrzeba zapewnienia im odpowiedniej ilości jedzenia, szczególnie podczas weekendowych wyjazdów. Przeglądając gotowe rozwiązania stwierdziłem, że najlepiej zbudować samemu mając przy tym sporo frajdy i satysfakcji. Urządzenie zostało zbudowane w oparciu o: Raspberry Pi Zero W Kamera do Raspberry Pi Serwo L360 Uchwyt na kamerę Czujnik odległości Główne cechy urządzenia Zdalna możliwość karmienia z dowolnego miejsca na świecie podgląd z ruchomej kamery ultradźwiękowy czujnik wykrywający kota oświetlenie IR pozwalające na podgląd w nocy możliwość wgrywania i odtwarzania dowolnych plików audio opcja "Text To Speach" duży 10 litrowy zbiornik na karę detekcja pustego zbiornika harmonogram automatycznego podawania karmy Pierwszym etapem i najtrudniejszym było wykonanie niezawodnego mechanizmu podającego karmę. Przetestowałem kilka rozwiązań: podajnik ślimakowy mechanizm koszykowy zasuwa podajnik tłokowy - to rozwiązanie sprawdziło się świetnie Układ podający powstał z ogólnodostępnych elementów PCV Niżej widok od tyłu pokazujący montaż tłoka Na filmie pokazana jest idea pracy mechanizmu, były to pierwsze próby ze słabszym serwomechanizmem. Ostatecznie został wymieniony na L360, a ruch obrotowy samego serwa zastąpiony ruchem "po łuku - przód, tył" co pozwoliło zapobiec ewentualnemu zakleszczeniu się karmy. Mechanizm - film Kolejnym etapem było wykonanie dodatkowej elektroniki obsługującej: 2 serwa do kamery 1 serwo podające karmę wzmacniacz audio czujnik odbiciowy IR czujnik zbliżeniowy Dodatkową wyzwaniem było przerobienie zwykłej kamery na kamerę NoIR, w tym celu zdemontowałem układ optyczny i delikatnie usunąłem filtr podczerwony. Poniżej wygląd matrycy po zdemontowaniu tych elementów. Po ponownym zamontowaniu soczewki, kamera działała już prawidłowo przy oświetleniu podczerwonym. Poniżej widok od spodu: Główne oprogramowanie sterujące sprzętem zostało napisane w pythonie, a interfejs użytkownika w PHP, na raspberry pi jest postawiony serwer www razem z mysql, tak więc jest to mały potworek do karmienia kotów. Sterowanie odbywa się przez stronę www, co wyeliminowało pisanie dedykowanej aplikacji na każdy z systemów osobno. Na koniec kilka dodatkowych zdjęć
  24. 8 punktów
    Pojawiło się zapotrzebowanie na zegar cyfrowy, który będzie miał duże cyfry, przynajmniej 8-10cm wysokości. Dodatkowym wymaganiem było to, że cyfry nie mogą być czerwone. Wykluczyło to praktycznie wszystkie wyświetlacze 7-segmentowe. Dodatkowo cena wyświetlaczy tej wielkości jest już znaczna, koszt 4 sztuk to wydatek mniej więcej 200zł. Z tego powodu powstał pomysł realizacji takiego zegara na diodach WS2812. Po wykonaniu wstępnych projektów, zegar miał mieć cyfry wysokości ok 14cm, po dwie diody na segment, a obudowa miała zostać wykonana na drukarce 3D. Cały układ sterujący miał się znaleźć pomiędzy cyframi godzin i minut, co znacznie ograniczyło miejsce na podzespoły. Na początku układ miał bazować na Atmedze 8, jednak po dłuższych poszukiwaniach zdecydowałem się na Attiny814. W sieci nie ma zbyt wielu materiałów na temat tego procesora, jednak jego dokumentacja jest chyba jedną z najlepszych, z jakich miałem okazję do tej pory korzystać. Ponieważ nie jestem fanem ustawiania godziny poprzez przyciski, to zegar miał mieć możliwość zdalnego sterowania. Ostatecznie wybór padł na moduł Bluetooth HM-10. Do odmierzania czasu użyty został zegar DS1307 wraz z baterią CR2032. Dodatkową funkcjonalnością jest pomiar temperatury poprzez ADC i czujnik LM35. Konieczny był także pomiar jasności otoczenia, aby umożliwić automatyczne dostosowywanie się jasności diod. Wykorzystany został do tego zwykły fotorezystor. Jak się okazało, kompilowanie programów na Attiny81x przez gcc i Makefile nie jest proste i oczywiste. Przede wszystkim konieczne jest wykorzystanie gcc w wersji 8.x, oraz trzeba pobrać odpowiednie pliki nagłówkowe ze strony atmela, ponieważ avr-libc ich (jeszcze) nie dostarcza. Kolejnym wyzwaniem był programator, ponieważ Attiny814 korzysta z interfejsu UPDI, nie da się go zaprogramować poprzez USBasp. Programatory UPDI są kilkadziesiąt razy droższe od Attiny814, dlatego mocno wskazane było znalezienie jakiejś alternatywy. Okazało się nią jtag2updi, pozwalające na programowanie poprzez konwerter USB-UART oraz dowolny procesor, przy czym autor dostarcza gotowe wsady do atmegi328p (arduino). Sporą wadą takiego rozwiązania jest brak możliwości korzystania z debuggera, ale z odrobiną cierpliwości i oscyloskopem dało radę i bez niego. Diody led połączone są w dwa łańcuchy, było to konieczne ze względu na budowę zegara, a także pozwoliło zoptymalizować czas pełnego odświeżenia wyświetlacza. Ważne było, aby przeładowywać wszystkie diody w czasie mniejszym niż czas trwania jednego bajtu wysyłanego poprzez UART z prędkością 9600 baud. Wynikało to z faktu, że diody mają bardzo niewielki czas trwania jednego bitu, wynoszący ok 1.25us, przez co konieczne było wyłączenie przerwań na czas przeładowywania diod. Diody WS2812 działają na tej zasadzie, że pierwsza dioda w łańcuchu odbiera 3 bajty (24 bity) danych, a każde kolejne ignoruje i przesyła dalej. W przypadku przerwy w transmisji dłuższej niż 50us stan transmisji jest resetowany i pierwsza dioda zaczyna ponownie odbierać 3 bajty dla siebie. Aby zapewnić czasy możliwie najbardziej zbliżone do tych w dokumentacji, funkcja odświeżająca diody została napisana w assemblerze. Ponieważ nie posiadam drukarki, która umiałaby drukować dwoma kolorami jednocześnie, to cyfry składają się z czarnego szkieletu oraz białych wkładek, wydrukowanych oddzielnie. Efekt jest całkiem dobry. Aby jeszcze nieco poprawić równomierność świecenia segmentów cyfry zostały od środka pomalowane farbą akrylową na biało. Z racji tego że każdy segment składa się z dwóch diód, to możliwe jest wyświetlanie dwukolorowe, dające całkiem ciekawy efekt, jednak z braku czasu na razie zegar jest w stanie świecić tylko na jeden wybrany kolor. Na zdjęciu powyżej niektóre segmenty są pomalowane farbą od środka, stąd te ciemniejsze ramki, ostatecznie wszystkie wkładki zostały wymienione na takie bez farby. Do sterowania zegarem napisana została aplikacja w React Native, pozwalająca na ustawianie czasu, koloru oraz dodatkowych efektów. Komunikacja odbywa się poprzez wspomniany wyżej Bluetooth. Wskaźniki jasności były przydatne głównie w fazie rozwoju zegara, między innymi do testowania korekcji gamma. W aktualnej wersji zegar nie wysyła już pomiarów, ale w razie czego możliwe jest ich przywrócenie. Ostatecznie pomiar temperatury okazał się dość nieskuteczny, ponieważ termometr jest w środku obudowy, to pokazuje temperaturę wyższą niż jest w rzeczywistości. Wynika to między innymi z faktu, że podzespoły w środku nie są idealne i wydzielają trochę ciepła, na tyle dużo że temperatura zawyżona jest o 2-3°.
  25. 8 punktów
    Od pewnego czasu na forum pojawiają się artykuły o możliwości wykorzystania nieco większych mikrokontrolerów w robotyce. Przez większe, rozumiem procedory ARM9, ARM11 lub Cortex-Ax. Niewątpliwą zaletą takich układów jest możliwość wykorzystania systemu operacyjnego z komputerów PC, a częstym wyborem jest Linux. [blog]https://forbot.pl/blog/artykuly/programowanie/linux-programowanie/sprawdz-jak-tanio-zbudowac-robota-z-systemem-linux-id7751[/blog]
  26. 8 punktów
    Odkryłem ciekawy sposób na darmowe płytki drukowane dla uczniów i studentów i postanowiłem się nim z wami podzielić. Najpierw podam instrukcje potem opiszę możliwości produkcyjne i otrzymane dzisiaj płytki. NIEAKTUALNE! NOWE INSTRUKCJE TUTAJ! Instrukcje: 1. Wchodzimy w link. Jest to mój reflink po rejestracji z którego dostajecie dodatkowe $5 na płytki (4 warstwy etc.). 2. Rejestrujemy się poprzez wyświetlony formularz. 3. Wysyłamy z konta e-mail na który się zarejestrowaliśmy maila do service@pcbway.com ze zdjęciem legitymacji uczniowskiej/studenckiej i informacją że chcemy skorzystać z http://www.pcbway.com/free_pcb.html. 4. Czekamy na odpowiedź. 5. Składamy zamówienie przez stronę, czekamy aż status zmieni się na "ready to pay" jeszcze nic nie płacimy. 6. Odpisujemy na ostatniego maila (z potwierdzeniem kwalifikacji do programy darmowych płytek) z prośbą o adres do zapłacenia kosztów przesyłki. 7. Płacimy podane koszty przesyłki na ten adres przez PayPal. Koszt przesyłki to $10 za 7 dni albo $25 za 3 dni. Do tego dochodzi czas produkcji - max. 4 dni. 8. Czekamy na płytki. Ograniczenia darmowych płytek: 1. Wielkość płytki 10cmx10cm. 2. Maksymalnie 2 warstwy. 3. Ilość kopii: 5 lub 10. 4. Minimalny rozmiar wiertła 0.3mm. 5. Minimalna szerokość ścieżki 6 mil. 6. Na jednej płytce maksymalnie jeden unikalny projekt. 7. Maksymalnie 30 płytek w zamówieniu (chodzi o panelizacje). 8. Kolor soldermaski: czerwony, niebieski, zielony, żółty. Ceny płytek poza programem studenckim to $13 za 2, $35 za 4 i $154 za 6 warstw. Za dodatkową opłatą można ominąć ograniczenia z powyższej listy. Za umieszczenie na ich stronie zdjęć otrzymanych płytek można dostać $5 do wydania u nich. Moje obserwacje: Zamówiłem u nich płytki 3x5cm, 10 sztuk. Otrzymałem je po 10 dniach pomimo wybrania tańszej przesyłki. Jakość moim zdaniem co najmniej równa Satland Prototype. Soldermaska idealnie ostra i równa, silk screen bardzo czytelny, nawet gdy bardzo mały (opisy pomiędzy padami elementu 1206). Wszystkie warstwy są dobrze nałożone, otwory wycentrowane. Dobrze się lutuje. Został dodany numer identyfikacyjny płytki na silk screenie pod elementem. Galeria: Skan gotowej płytki (białe wewnątrz otworów to tło skanera): Stosik otrzymanych płytek: Zlutowana płytka (będzie wkrótce osobno opisana):
  27. 8 punktów
    Ten robot był eksperymentem w kilku dziedzinach jednocześnie. Po pierwsze, jest to mój pierwszy skończony dwunożny robot kroczący. Po drugie, jako mózgu użyłem nowego wówczas układu ESP8266. Po trzecie, po raz pierwszy użyłem sub-micro-serwa zasilane napięciem 3V. Na koniec, nawet obudowa była eksperymentem, sprawdzającym jak dobrze plastik ze starych opakowań nadaje się do tego celu. Później dla tego własnie robota wytrawiłem swoją pierwszą płytkę drukowaną. Ostatnim eksperymentem, który się niestety już nie powiódł, było użycie optycznego cyfrowego czujnika odległości, który z jakiegoś powodu okazał się nie działać. Ale do rzeczy. Robot ten bardzo mocno bazuje na projekcie znanym ogólnie jako "Bob" (http://www.robotrebels.org/index.php?topic=11.0). W zasadzie jest to moje podejście do zrobienia jego miniaturoej, pomniejszonej wersji. Niestety nie posiadałem dostępu do drukarki 3D, żeby zrobić obudowę i szkielet, zatem podszedłem do tematu tak jak zwykle -- zlepiając ze sobą losowe części i lutując wszystko "na pająka". Wyszło mi coś takiego: Dużym wyzwaniem były gniazdka do serw, bo ich rozstaw nóżek to 1.27mm. Moduł ESP8266, którego użyłem, ma rozstaw padów 2mm, więc już trochę łatwiej. Diody świecące dodałem, żeby widzieć czy robot jest włączony czy nie. Stopy są wycięte ze starej karty kredytowej. Gumka recepturka przytrzymuje baterię. Zadowolony z tej konstrukcji, postanowiłem zrobić do niej obudowę ze starego opakowania (tak zwanego "blistera") po gamepadzie. Wyciąłem z niego kawałek w miarę płaskiego plastiku, narysowałem na nim siatkę pudełka, wyciąłem i skleiłem Kropelką. Po dopasowaniu do robota powycinałem otwory. Potem dokleiłem trochę kawałków starych zabawek do ozdoby... Z czasem wymieniłem stopy na wykonane z takiego samego materiału jak obudowa i dodałem robotowi moduł ładowania baterii (jest to pojedyncze LiPo, więc dość łatwo je ładować). Do programowania wykorzystałem powstający wówczas dopiero firmware NodeMCU dla ESP8266, który pozwolił mi oskryptować wszystko w Lua. Było to bardzo wygodne, gdyż mogłem na żywo testować kod w konsoli, na którą po prostu łączyłem się telnetem. Przy okazji próby używania PWM do kontrolowania serwomechanizmów, znalazłem dwa błędu w NodeMCU, które zostały szybko poprawione (https://github.com/nodemcu/nodemcu-firmware/issues?q=is%3Aissue+author%3Adeshipu+is%3Aclosed). Jest tu zastosowany jeden trik, gdyż NodeMCU obsługuje co najwyżej 3 kanały PWM (zrobili to do kontroli diody RGB), a ten robot ma 4 serwomechanizmy. Otóż dwa z tych serwomechanizmów sterowane są tym samym sygnałem i zawsze mają tę samą pozycję -- to nie przeszkadza przy tym sposobie chodzenia, jaki ma ten robot: W tym stanie robot postał na półce jakiś rok -- zabrałem go na dwie konferencje, żeby się pochwalić. Niestety, po powrocie z ostatniej przestał działać -- urwał się jeden z padów na ESP8266, do których przylutowane były druciki. Niestety nie dało się tego naprawić bez praktycznego przebudowania całego robota, więc robot sobie leżał i czekał na lepsze czasy. Lepsze czasu nadeszły, gdy kupiłem odczynniki do trawienia płytek i postanowiłem spróbować w tym swoich sił. Zrobiłem płytkę dla naszego bohatera: A w zasadzie całą serię płytek, gdyż nie udało mi się jej poprawnie wytrawić za pierwszym razem: W końcu udało się zrobić coś, co miało większość potrzebnych połączeń i wywiercić w tym otwory, łamiąc przy tym tylko trzy wiertła. Po zlutowaniu całości, tak jak wspomniałem wcześniej, czujnik odległości okazał się nie działać, ale robot nadal chodzi i do tego teraz może mrugać oczami: Być może jeszcze kiedyś wrócę do tego projektu i spróbuję uruchomić ten czujnik, albo użyć innego. Mógłbym też znacznie rozszerzyć jego repertuar zachowań, na przykłąd nauczyć go tańczyć. Ogólnie z robota jestem bardzo zadowolony, dostarczył mi naprawdę wiele zabawy przy budowie i nauczył przy tym dużo, choć jest to chyba projekt przy którym jak dotychczas napsułem najwięcej komponentów (w sumie dwie płytki esp8266, jeden sensor optyczny, który zniszczyłem przy lutowaniu, milion nieudanych płytek, wiertełka). __________ Komentarz dodany przez: Treker 1 - Poprawiłem temat, w którym nie działał encja µ. 2 - Typ robota należy wybierać z listy rozwijanej zamiast wpisywać go ręcznie. 3 - Opisy robotów muszą zawierać jedno zdjęcie w załączniku, które jest prezentowane w katalogu robotów oraz na stronie głównej. Tym razem poprawiłem, pamiętaj proszę na przyszłość o tych zasadach. [ Dodano: 14-10-2015, 11:06 ] 1 - Nie lepiej by było naprawić forum tak, żeby działała? 2 - Nie widziałem tam nigdzie listy rozwijanej. UPDATE: Już widzę, jest na szaro po stronie etykiety pola, musiałem jakimś cudem przeoczyć, przepraszam. Jakoś mogę to naprawić? 3 - Jestem pewien, że załączyłem jedno zdjęcie jako załącznik, własnie tak, jak piszesz. Nie mam pojęcia czemu się to nie pojawiło. Poprawiłem teraz.
  28. 8 punktów
    Cześć! Jako że już po sezonie to postanowiłem opisać tu moją i mateuszm konstrukcję. Robot powstał w ramach rekrutacji do koła naukowego robotyków KoNaR i debiutował na Robotic Arenie 2015. Był to nasz debiut w konstruowaniu robotów, ponieważ wcześniej żaden z nas tego nie robił. Mechanika Głównym założeniem mechaniki robota było wykorzystanie w pełni maksymalnej dopuszczalnej masy oraz skupienie jej w podstawie. W osiągnięciu tego celu pomógł nam projekt Autodesk Inventor, w którym to został wykonany szczegółowy projekt robota uwzględniający wszystkie drobne elementy mechaniczne. Podstawa robota została wykonana z trzech elementów: - ostrze z węglika spiekanego - płytka stalowa 3mm - płytka górna, 2mm, która łączyła dwa elementy wymienione wyżej W płytkach zostały wycięte otwory, w których następnie umieszczone były małe, okrągłe płytki z czujnikami białej linii. Stal była cięta laserowo oraz później frezowana. Napęd robota stanowiły znane i lubiane silniczki Pololu HP z przekładnią 50:1 przykręcone bezpośrednio do podstawy za pomocą dedykowanych mocowań. Podpięte do elektroniki były przy pomocy złączy ARK co umożliwiło ich łatwy demontaż w celach serwisowych. Obudowa robota została wykonana z laminatu 1mm. Na obudowie znajduje się nazwa robota oraz nasze imiona i nazwiska. Obudowa mocowana jest do podstawy za pomocą śrub, a jej elementy są do siebie lutowane. Dach robota wykonaliśmy z 2 mm przeźroczystego szkła akrylowego. Finalnie robot mierzy w najwyzszym miejscu 33,7 milimetra od podstawy do dachu, a od podłoza do dachu 37,2. Jego podstawa ma wymiary 98,9 mm na 99,6 mm. Masa waha się od 490 do 499g w zależności jak bardzo nakarmimy robota przed zawodami Elektronika Priorytetem projektu robota była jego dobra konstrukcja mechaniczna, w wyniku czego wymiary płytki z elektroniką były z góry narzucone. Elektronika została zaprojektowana w programie KiCad po zaimportowaniu wymiarów przeznaczonych na nią z programu Inventor. Elektronika robota dzieli się na dwie płytki: główną, która znajduje się tuż nad podstawą robota oraz dodatkowej, na której umieściliśmy włącznik zasilania, interfejs komunikacyjny oraz złącze na moduł startowy. Płytki połączone zostały ze sobą taśmą FFC. Mała płytka widoczna na zdjęciu nad płytką główną służy nam jako podstawka pod akumulator LiPo 7.4V, którym zasilamy robota. Sercem naszego robota został mikroprocesor STM32F1. Wybór tej rodziny wynikał z łatwości ich programowania przez początkujących. Czujniki odległości wykorzystane w robocie to znane i lubiane cyfrowe Sharpy 40cm. Umieściliśmy je 4, dwa z przodu oraz po jednym na bokach. Na czujniki białej linii użyliśmy dwa KTIRy 0711S. Jak wcześniej wspomniałem zostały one umieszczone na małych płytkach, które umieściliśmy w wycięciach w podstawie. Na sterowniki silników wybraliśmy dwa, podwójne mostki H TB6612. Zostały one dobrane ze względu na ich dobrą wydajność prądową, co umożliwiło nam skuteczne wysterowanie silników Pololu bez obawy o to, że przy pełnym zwarciu mostki ulegną uszkodzeniu. Płytki zostały wykonane metodą termotransferu oraz wyfrezowane za pomocą Dremela i pilników ręcznych. Software Kod robota został napisany w środowisku System Workbench for STM32 (SW4STM32) z użyciem generatora kodu konfiguracyjnego STM32CubeMX. Program podzielony był na dwie sekwencje: startową i walki. W pierwszej ustawiana była konfiguracja algorytmu robota oraz dostępne były funkcje testu czujników (widoczny na zdjęciu poniżej - cztery czerwone diody, które odpowiadały za pokazanie aktualnego stanu czujników) oraz czyszczenia kół (drobna funkcja pomocnicza ustawiająca małą prędkość na kołach). Sekwencja walki załączała się po otrzymaniu przez robota sygnału startowego z modułu. Większa część algorytmu walki opierała się na prostych if-ach z odpowiednio dobranymi nastawami silników w każdym przypadku, co okazało się wystarczające w większości starć. Następnie zostały dodane pewne udoskonalenia, o których już rozpisywać się nie będę Osiągnięcia - II miejsce Robomaticon 2016 - I miejsce Robotic Tournament 2016 - III miejsce Festiwal Robotyki Cyberbot 2016 - II miejsce [Minisumo] oraz I miejsce [Minisumo Deathmatch] Trójmiejski Turniej Robotów 2016 - II miejsce Opolski Festiwal Robotów 2016 - I miejsce Robotic Day 2016 [Praga] A poniżej kilka filmów z udziałem robota: 2Weak4U vs Hellfire 2Weak4U w Wiedniu 2Weak4U vs Dzik 2Weak4U vs Shevron (chyba) 2Weak4U w Deatmatchu [Rzeszów] 2Weak4U vs Szwagier Pozdrawiam i do zobaczenia w następnym sezonie, Aleksander
  29. 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.
  30. 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:
  31. 7 punktów
    Skoro forum powoli zmienia profil i przestajemy się skupiać na robotach, to postanowiłem, że zrobię sobie tutaj trochę bezczelnej reklamy i napiszę o projekcie, nad którym pracowałem od jakiegoś roku, który choć związany z mikrokontrolerami i programowaniem, robotem stanowczo nie jest. Zaczęło się mniej więcej rok temu, kiedy wpadłem na pomysł jak można sprawić, żeby nauka języka Python była znacznie łatwiejsza, mniej problematyczna oraz przede wszystkim fascynująca. Micro:bit i Raspberry Pi pokazały, że programowanie dedykowanego urządzenia daje bardzo dużo radości oraz poczucie kontroli nad techniką — moim zdaniem bardzo ważne rzeczy przy uczeniu jakichkolwiek technicznych tematów. Niestety, moje doświadczenia z przeróżnych szkoleń i warsztatów pokazały także achillesową piętę takiego podejścia: zawsze coś nie działa. Ludzie przychodzą z własnymi laptopami, niektórzy mają na nich poinstalowane jakieś Windowsy czy inne Makoesiksy, połowa z nich nie potrafi zainstalować sterownika, druga połowa akurat miała system update i sterownik im przestał chodzić, trzecia połowa dopiero ściąga prze konferencyjne WiFi środowisko uruchomieniowe i kompilator, a czwartej połowie nie chcą zainstalować się biblioteki. W efekcie ponad połowa czasu zawsze jest tracona na ustawianie wszystkiego. Do tego kiedy już uczniowie napiszą te swoje gry i będą chcieć się nimi pochwalić, to nie będą mogli — bo działają tylko na ich komputerze gdzie jest wszystko zainstalowane, a uruchomienie na komputerze kolegi wymaga przechodzenia całego procesu ponownie. Koszmar. Zatem postanowiłem zrobić urządzenie dedykowane do pisania gier, usuwając przy tym z drogi jak najwięcej przeszkód tak, aby można się było skoncentrować na celu — czyli samym programowaniu — bez wszystkich dodatkowych problemów. Początkowo stworzyłem shield dla płytek sprzedawanych przez Adafruit, zawierający przyciski i prosty kolorowy wyświetlacz LED 8x8, aby dało się pisać gry w rodzaju snake-a czy tetris-a. Jednak nie było to jeszcze rozwiązanie idealne, choć pozwoliło mi zbadać co działa, a co nie, oraz doszlifować moje umiejętności. Dzisiaj udostępniam szerszej publiczności moje najnowsze dzieło, czyli "prawdziwą" przenośną konsolę do gier. Zawiera ona kolorowy ekran 128x128, głośniczek, 6 przycisków i mikrokontroler programowany w CircuitPythonie. Urządzenie po podłączeniu do komputera widoczne jest jako dysk USB, nie wymagając przy tym żadnych sterowników (chyba, że ktoś ma Windows 7, wtedy niestety konieczne jest zainstalowanie sterownika aby mieć dostęp do konsoli na porcie szeregowym), a programujemy je po prostu edytując widoczne na nim pliki (lub kopiując je z komputera, oczywiście). Wbudowana w firmware prosta biblioteka do obsługi duszków i kafelków ułatwia zadanie. Grafika jest trzymana w plikach BMP, dźwięki w plikach WAV, kod w plikach tekstowych — zatem można użyć dowolnego programu jaki akurat się ma dostępny i jaki umie się już obsługiwać. Więcej informacji o projekcie, wraz z logami z jego konstruowania można znaleźć na https://hackaday.io/project/27629 Tylko, że co daje taki projekt zrobiony dla siebie do szuflady? Oczywiście wszystko jest opisane i opublikowane na otwartych licencjach, ale szanse na to, że ktoś inny zbuduje takie urządzenie są w zasadzie znikome. Aby było ono rzeczywiście przydatne, ludzie muszą go używać, a zatem musi być ono dostępne w sprzedaży. Dlatego kolejnym moim krokiem było zlecenie wyprodukowanie małej serii tych urządzeń. Dzisiaj właśnie przyszła paczka z fabryki i rozpoczynam ich sprzedaż na Tindie. Jest ich tylko 50, nie liczę na zbicie na tym kokosów, ale być może uda się zbudować społeczność zainteresowaną programowaniem tych urządzeń. Oczywiście jak na polskie warunki cena jest wysoka — niestety tak to jest z produkowaniem małych serii niestandardowych urządzeń. Ale być może kogoś jednak to zainteresuje: https://www.tindie.com/products/deshipu/game-10-game-console-kit/ Wreszcie, żeby nie było, że to tylko taka reklama i komercja, bardzo chętnie pomogę ludziom chcącym zbudować swoją własną wersję tej konsoli. Nie trzeba do tego wytrawiać płytek i lutować elementów montowanych powierzchniowo — wystarczy dowolna płytka rozwojowa z mikrokontrolerem SAMD21, moduł wyświetlacza, kilka przycisków, trochę kabelków, kostka pamięci flash i opcjonalnie głośniczek lub słuchawki.
  32. 7 punktów
    Cześć. Chciałbym przedstawić wam mój projekt robota samobalansującego. Jest to mój najbardziej zaawansowany jak dotąd projekt, który pochłonął najwięcej pracy. Pomysł na zbudowanie takiego robota zrodził się w mojej głowie w wakacje po obejrzeniu filmiku przedstawiającego podobną konstrukcję. Pracę nad nim rozpocząłem jeszcze w wakacje, a z przerwami zakończyłem w lutym. Działanie robota jest podobne do dostępnych na rynku Hoverboardów, czyli robot ma za zadanie poruszać się w taki sposób, aby utrzymać się w pionie, oczywiście bez podpierania. Konstrukcję robota zaprojektowałem sam i wykonałem z pręta gwintowanego i plexi. Uznałem że taka konstrukcja zapewni robotowi wymaganą sztywność i niską masę, jednocześnie nie rujnując budżetu. Najpierw wykonałem jej model w Fusion 360, a później przystąpiłem do pracy. Roboty z tym trochę było, bo obróbka plexi do łatwych nie należy. Sporo czasu zajęło przycięcie prostokątów, a jeszcze więcej wywiercenie otworów, które musiały być idealnie rozmieszczone, aby później dało się przełożyć przez nie pręt gwintowany. Po zbudowaniu ramy przyszła pora na elektronikę. Ponieważ robot nie zapewnia dużo miejsca, a jednocześnie środek ciężkości powinien być możliwie wysoko, dla ułatwienia balansu, musiałem się postarać ścisnąć wszystko jak to tylko możliwe. Baterię zasilającą robota (ogniwe Li-Po odzyskane z powerbanka o pojemności 3000 mAh) umieściłem na najwyższej półce. Tam również trafiła przetwornica step-up podnosząca napięcie do 7,4 V. Wiem że lepiej byłoby dać dwie baterie połączone szeregowo, ale w momencie budowania budżet na to nie pozwolił. Szybko okazało się że jedna przetwornica to za mało - Arduino restartowało się przy każdym uruchomieniu silnika, nawet jeśli do układu przyłączyłem bardzo duży kondensator. Dodałem więc drugą - teraz silniki były zasilanie niezależnie od elektroniki sterującej. Pozwoliło to stanąć robotowi po raz pierwszy, jednak wciąż jedna przetwornica zasilająca silniki ograniczała ich moc. Dodałem drugą, co nieco poprawiło sytuację, jednak wciąż nieco ogranicza silniki. Póki co szukam lepszego rozwiązania. Schodząc na niższą półkę. Tam trafiła płytka ze sterownikiem i druga z mostkiem H. Pierwszą płytkę lutowałem sam na płytce uniwersalnej - zajęło to kilka godzin i mnóstwo cyny, ale satysfakcja była nie do opisania, zwłaszcza że wszystkie połączenia wykonałem cyną. Po spędzeniu kolejnej godziny na pozbywaniu się zwarć układ był gotowy do testów Robot aby ustalić swoją pozycję korzysta z modułu żyroskopu i akcelerometru MPU6050 oraz wbudowanych w silniki enkoderów. Dane z tych czujników trafiają do Arduino Nano które poprzez układ L298N steruje dwoma silnikami. Dzięki akcelerometrowi i żyroskopowi robot zna swój kąt przechylenia. W pierwszych wersjach kodu szybko okazało się, że to nie wystarczająco, ponieważ o ile robot stał, to cały czas przesuwał się w jedną stronę. Wynika to z tego że konstrukcja nie jest idealnie wyważona, a robot nie zna swojej pozycji, jedynie kąt nachylenia, więc jeżeli ustawiony na sztywno kąt odbiegał od kąta balansu, robot "dryfował". Aby temu zapobiec dodałem drugie sprzężenie zwrotne, tym razem oparte o enkodery przy silnikach. Enkodery zliczają ilość impulsów które silniki wykonały w każdą ze stron, a oprogramowanie dąży, aby ich różnica była równa 0. Pierwsze próby nie były zbyt udane. Kiedy doprowadziłem kod do stanu w którym robot chociaż próbował się utrzymać, udawało mu się to przez maksymalnie kilkanaście sekund. Jednak wraz z poprawianiem kodu robot stał dłużej i dłużej. Obecnie już się nie wywala, jednak mostek H po dłuższym staniu się przegrzewa, więc czas pracy ograniczony jest do kilku minut. Mimo to robot robi duże wrażenie, chociaż z pewnością nie jest idealny. Zastosowałem tanie chińskie silniki, i jak się okazało, jeden obraca się szybciej niż drugi, więc robot obraca się w jedną stronę. Do tego jak wspomniałem przegrzewa się, a silnikom brakuje momentu, więc robot się trzęsie zamiast stać idealnie prosto. Są to jednak problemy które mam w planach poprawić. Planuję dodać również możliwość sterowania po BT (już nawet na płytce jest miejsce na moduł HC-06), ale na razie nie miałem czasu. Oto filmik prezentujący działanie robota:
  33. 7 punktów
    Witajcie. Chciałbym Wam przedstawić prosty sposób wykorzystania modułu ESP-32, który użyłem do stworzenia urządzenia, za pomocą którego możecie śledzić poziom zainteresowania wybranym repozytorium GitHub. Dzięki wbudowanym dwóm wyświetlaczom, będziecie na bieżąco informowani o: aktualnej liczbie gwiazdek dziennej liczbie gwiazdek aktualnej liczbie obserwujących aktualnej liczbie forków Początkowo chciałem skorzystać ze starszego modułu ESP8266 12-F, jednak napotkałem problem który objawiał się przy wykonywaniu requesta do api GitHub. Podczas oczekiwania na odpowiedź z serwera, na wyświetlaczach zanikały wszystkie cyfry i wyglądało to jakby coś było nie tak z urządzeniem. Z pomocą przyszedł układ ESP-32, który oparty jest na dwóch rdzeniach. Była to świetna okazja aby zapoznać się z tym modułem, ponieważ wcześniejsze projekty wykonywałem na ESP8266. Użycie nowszej odsłony ESP, pozwoliło mi wysyłać requesty asynchronicznie. Do działania ramki wymagane jest połączenie z siecią poprzez WiFi. Tutaj świetnie sprawdziła się biblioteka "WiFi Manager", która umożliwiła mi szybkie podłączenie ramki do dowolnej sieci. Jeżeli chodzi o zasilanie to jest to napięcie 5V, które podaje poprzez wtyki USB. W obudowie ramki znajdują się trzy przyciski. Pierwszy służy jako włącznik. Pozostałe dwa to włączniki chwilowe. Po wciśnięciu pierwszego na wyświetlaczu prezentowany jest adres IP, który wykorzystujemy przy konfiguracji. Natomiast drugi przycisk resetuje liczbę gwiazdek z dnia. Do układu podłączona jest 3 kolorowa dioda LED, która informuje nas o stanie połączenia: CZERWONY – brak sieci, błąd podczas pobierania danych ZIELONY – połączenie sieciowe ustanowione, dane pobrane poprawnie NIEBIESKI – tryb access pointu ( zanik sieci ) Domyślnie odświeżanie danych odbywa się co 90 sekund. Oczywiście interwał można zmienić. Ale należy uważać, aby nie wykonywać do api GitHub więcej niż 60 requestów na godzinę, ponieważ serwer ma ustawiony RateLimit. Po przekroczeniu ilości zapytań zostaniemy zablokowani na godzinę. Jak już wspomniałem wyżej, pod adresem IP jaki przydzielony został do urządzenia działa prosty web server, który serwuje nam stronę z konfiguracją, gdzie musimy wprowadzić nazwę użytkownika repozytorium oraz nazwę repozytorium które chcemy obserwować. Po zapisaniu konfiguracji w pamięci EEPROM urządzenie jest restartowane i gotowe do użycia. Dodatkowym atutem urządzenia jest automatyczna aktualizacja oprogramowania poprzez HTTPS OTA. Sprawdzanie wersji następuje podczas uruchomienia oraz po północy. Urządzenie jest w pełni bezobsługowe. Gdy wystąpi zanik sieci, ESP cały czas będzie próbowało nawiązać połączenie za pośrednictwem zapamiętanych poświadczeń. Jeśli sieć nie będzie dostępna, przełączy się w tryb access pointu ( ssid: "GITHUB-FRAME"). Jeśli nie zostanie wybrana nowa sieć w menadżerze sieci, to po czasie 3 minut, nastąpi restart i proces się powtórzy. Tak pokrótce, wygląda zasada działania całego układu. Poniżej przedstawię Wam główne etapy budowy całej ramki. A więc zaczynamy. LISTA ELEMENTÓW: ESP-32 WROOM DevKit 1.0 – 1 szt. Wyświetlacz LED 4-Cyfrowy TM1637 – 0.56" – 1 szt. Wyświetlacz LED 4-Cyfrowy TM1637 - 0.36" – 1 szt. 4-pinowy przewód, żeński – żeński – raster 2.54 – 4 szt. Gniazdo + wtyk, JST – JST – 2 szt. Gniazdo + wtyk, mikro JST – mikro JST – 2 szt. Płytka uniwersalna PCB 50x70mm PI-01 – 1 szt. Rezystor węglowy – 220 ohm – 5 szt. Rezystor węglowy – 2,2k ohm – 3 szt. Zworki do płytek stykowych - 1 zestaw Wtyk goldpin kątowy 4 pinowy, raster 2,54mm – 4 szt. Dioda LED 5mm RGB wsp. Anoda – 1 szt. Dioda LED 3mm biała – 3 szt. Przełącznik chwilowy okrągły – 10mm – 2 szt. Przełącznik kołyskowy ON-OFF – 1 szt. Kabel USB A – USB micro – 1 szt. Zasilacz 5V z gniazdem USB A – 1 szt. Rurki termokurczliwe - 1 szt. Ramka IKEA RIBBA – 21x30cm ( ważne żeby była dość głęboka, aby zmieścić elektronkę ) – 1 szt. Papier samoprzylepny do drukarki – 1 szt. Rura elektroinstalacyjna RLM 16 – 1 szt. NARZĘDZIA: Lutownica Cyna Obcążki Wiertarka lub wkrętarka Wiertła: 7, 10, 13 Pistolet do kleju na gorąco Nóż Drukarka ZAŁOŻENIA: Stabilność działania Intuicyjna obsługa Szybka adaptacja w miejscu instalacji Estetyka Plan Początkowo ramka miała powstać pod konkretnie wybrane repozytorium i wyświetlać tylko liczbę gwiazdek. Ale stwierdziłem, że i tak pobieram inne dane z endpointa api to czemu miałbym ich nie wyświetlić. Postanowiłem, że dodam dwa nowe klucze: "forks" oraz "watchers" i wyświetlać je kolejno w 5 sekundowym odstępie czasowym. Jeżeli chodzi o repozytorium, to dając możliwość wprowadzenia własnych ustawień url-a, zwiększyłem tym samym skalowalność przedsięwzięcia. Do tego doszły automatycznie aktualizacje software-u. Więc taką ramkę może stworzyć każda osoba, która chociaż trochę ma pojęcie o informatyce i niekoniecznie zna się na programowaniu. BUDOWA Prace nad ramką rozpocząłem od budowy prototypu metodą na "pająka". W tym celu skorzystałem z płytki prototypowej, przycisków typu "tact switch", paru zworek oraz kilkunastu przewodów do połączenia wszystkiego w całość. Całe oprogramowanie zostało napisane za pośrednictwem Arduino IDE czyli w języku C. Gdy miałem już działający prototyp, rozpocząłem prace nad przeniesieniem całości na uniwersalną płytkę PCB. Zadanie wydawałoby się proste ale wymagało procesu planowania. W tym celu wykorzystałem oprogramowanie Fritzing. Oprogramowanie to umożliwia stworzenie całej dokumentacji projektu. Na tę chwilę wykorzystałem tylko narzędzie do stworzenia szkicu płytki prototypowej. Mając gotowy już projekt z rozlokowaniem wszystkich elementów i połączeń. Mogłem przystąpić do lutowania. Jak widać na zdjęciach, podczas montażu elementów używałem uchwytu, który stabilnie trzyma płytkę w miejscu. Bardzo ułatwił mi pracę. Po przylutowaniu wszystkich elementów elektronicznych, wlutowałem przewody z gniazdami, dzięki którym będę mógł odłączyć układ od samej konstrukcji ramki Teraz przyszedł czas na najtrudniejszy etap jakim było dostosowanie drewnianej ramki do potrzeb projektu. W programie Photoshop stworzyłem szablon do wiercenia i wycinania potrzebnych otworów. Szablony te znajdziecie również w repozytorium projektu. Po wydrukowaniu szablonu przykleiłem kartkę do “pleców ramki” i wyciąłem wszystkie otwory. Trochę trzeba się do tego przyłożyć i mieć sporo cierpliwości. Cięcie, pasowanie, cięcie, pasowanie aż do skutku. Ufff. W końcu mogłem przystąpić do zamontowania wyświetlaczy oraz diod LED. Z pomocą przyszedł mi klej na gorąco. Trzyma mocno i pewnie, wystarczająco do tego typu prac. Trzy diody LED umieściłem w przyciętych krążkach z białej rury pcv ( tych do prowadzenia przewodów po ścianach ) a górę zaślepiłem kawałkiem plastiku w którym zamocowałem diody. A tak całość prezentuje się od frontu Za pomocą 4 żyłowych przewodów zakończonych wtykami żeńskimi, połączyłem wszystkie elementy z główną płytką. W celu szybszej identyfikacji przewodów, oznaczyłem każde połączenie za pomocą lakierów do paznokci ( pozdrawiam swoją żonę Magdalenę ). Główny układ przykleiłem do pleców ramki również za pomocą kleju na gorąco. Na koniec pomalowałem cały front na biało farbą emulsyjną, ponieważ papier który używa się w drukarkach ma małą gramaturę co sprawia, że jest półprzezroczysty. Dzięki podbiciu koloru tła biel będzie intensywniejsza. W ostatecznej wersji grafikę wydrukowałem na papierze fotograficznym, który jest na tyle gruby, że malowanie okazało się być zbędne. SOFTWARE Cały program opiera się na dwóch pętlach. Pierwsza pętla Task1, sprawdza czy użytkownik wprowadził url repozytorium z którego mają zostać pobrane dane. Jeżeli konfiguracja została wprowadzona, program wywołuje funkcję getData(), która odpowiedzialna jest za pobranie danych z API. Interwał tej pętli definiuje zmienna requestInterval, która domyślnie posiada wartość 90 ( czyli 90 sekund). Druga pętla Task2, służy do wyświetlania odpowiednich danych na wyświetlaczach oraz podświetlania ikon. Tutaj również sprawdzany jest stan na pinach 27 i 15 ( przyciski BUTTON_IP oraz BUTTON_RESET_TODAY). Interwał tej pętli to około 15 sekund. Po północy następuje sprawdzenie dostępności nowszej wersji oprogramowania oraz resetowany jest licznik gwiazdek otrzymanych w ciągu całego dnia. Poniżej znajdziecie link do repozytorium z projektem: OPROGRAMOWANIE + SZABLONY DO DRUKU PODSUMOWANIE Przyznam się szczerze, że prototyp urządzenia miałem już gotowy rok temu. Ale ze względu na gruntowny remont mieszkania musiałem odsunąć hobby na dalszy plan. Rozciągnięcie projektu w czasie sprawiło, że przy każdym powrocie zawsze coś zmieniałem, rozbudowywałem. Wszystko wtedy można przemyśleć kilka razy i na spokojnie zastanowić się nad rozwiązaniem jakiegoś problemu. Na co dzień zajmuję się programowaniem front-endu, ale dzięki takim projektom mogę połączyć moje główne zainteresowania: majsterkowanie, elektronikę, grafikę i jak już wcześniej wspomniałem, programowanie i stworzyć coś namacalnego i cieszącego oko. Zachęcam wszystkich do twórczego działania i poszerzania swojej wiedzy. Tego typu projekty dadzą Wam satysfakcję, świetną zabawę oraz sporo nauczą. Także klawiatury, lutownice, piły, śrubokręty, wiertarki w dłoń i do działania! Instrukcję już macie Do następnego projektu! Pozdrawiam.
  34. 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.
  35. 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.
  36. 7 punktów
    Witam, Chciałbym przedstawić zbudowany ostatnio pojazd inspekcyjny. Założenia były następujące: dobra mobilność w nierównym terenie, sterowanie za pomocą aplikacji na Android'a oraz podgląd z wbudowanej kamery w czasie rzeczywistym. Mechanika W pojeździe zastosowano uproszczoną, 4-kołową wersję zawieszenia rocker-bogie stosowaną m.in. w łazikach marsjańskich. Główną zaletą tego rozwiązania jest niemal równomierny nacisk wszystkich kół na podłoże oraz możliwość uniesienia koła na przeszkodzie. Zastosowane koła pochodzą od "jakiejś" zabawki (znalezione na strychu ) i są zamocowane adapterem hex 12 mm (z małymi przeróbkami, aby schować przekładnię wewnątrz koła). Każde koło posiada własny silnik DC z przekładnią - prędkość wyjściowa: ok. 120 obr/min przy zasilaniu 12V. Silniki zostały zamocowane do aluminiowego profilu kwadratowego 10 mm za pomocą opasek zaciskowych. Profil ten stanowi część wahacza przymocowanego do osi kadłuba przez łożyska z wiertarek (średnica wewnętrzna 6 mm). Z tyłu pojazdu widoczna jest belka różnicowa łącząca wahacze po obu stronach. Dzięki niej kadłub utrzymywany jest w swojej pozycji a wychylenie jednego wahacza powoduje odchylenie drugiego o taki sam kąt przeciwnie skierowany. Jako kadłub wykorzystano obudowę z ABS. Do jej wieczka przymocowano również maszt z kamerą sterowany w dwóch osiach. Elektronika Komputerem sterującym w pojeździe jest Raspberry Pi Zero W z systemem Raspbian w wersji Jessie. Zastosowano ten model z powodu małych rozmiarów, stosunkowo niskiej ceny i małego poboru mocy. Z racji braku przetwornika ADC, zastosowano również arduino w wersji Pro Mini o napięciu 3.3V (aby było zgodne ze standardem w Raspberry). Są również 2 sterowniki silników na bazie modułu L298N (Sterownik ten ma dwa kanały i można było zastosować tylko jeden sterownik, jednak z powodu niewystarczającej wydajności prądowej zastosowano dwa), 2 przetwornice step-down 5V (osobno dla logiki, i osobno dla serwomechanizmów), dwa serwomechanizmy TowerPro SG90, kamera, oraz pakiet 3S ogniw li-ion w rozmiarze 18650. Z racji tego, że kamera jest podłączana przez taśmę FFC, zastosowano również przejściówki z FFC na goldpin, aby nie uszkodzić taśmy podczas obracania kamerą. Oprogramowanie Arduino w tym pojeździe odpowiedzialne jest za odczyt aktualnego napięcia zasilania oraz generowanie sygnałów PWM dla prędkości silników oraz serwomechanizmów pozycjonowania kamery. To jaki sygnał ma być generowany, jest wiadome dzięki połączeniu z Raspberry poprzez UART. Dodatkową funkcją Arduino jest wyłączenie PWM dla silników w przypadku braku komunikacji z Raspberry co zapobiega niekontrolowanej jeździe pojazdu w przypadku np. zerwania zasięgu. Raspberry komunikuje się z użytkownikiem poprzez sieć WiFi (Malinka działa w trybie hot-spot'u). Program działający na Raspberry został napisany w Python'ie i wykorzystuje również biblioteki Flask, w celu utworzenia serwera. Odpowiednie fragmenty kodu są wykonywane po wywołaniu przypisanego do niego adresu. Do transmisji wideo wykorzystano platformę Gstreamer, która pozwala na strumieniowanie w formacie H.264. Dzięki temu udało się uzyskać płynny obraz przy 30 FPS i rozdzielczości 800x600 cechujący się niewielkim opóźnieniem (ok. 300 ms). Powstała również dedykowana aplikacja na system Android, gdzie widoczny jest podgląd z kamery oraz sterowanie pojazdem. Podsumowanie Powstały pojazd zgodnie z założeniami dobrze radzi sobie w terenie, jednak pozostawia również spore możliwości rozbudowy. Można np. dodać zewnętrzną antenę WiFi aby poprawić zasięg (obecnie jest to ok 50m na otwartej przestrzeni), diodę doświetlającą, czy też różne czujniki. Najprawdopodobniej następnym krokiem będzie dodanie przetwarzania obrazów, aby pojazd był w stanie podążać za danym obiektem i być może omijać przeszkody. Na koniec krótka prezentacja działania:
  37. 7 punktów
    Robota chciałem opisać już od dłuższego czasu, jednak dopiero moje osiągnięcia na Robocompie 2014, pierwszych zawodach na jakich z nim byłem zmobilizowały mnie do stworzenia opisu. Osiągnięcia 1. Linefollower Light Robocomp 2014 3. Linefollower Standard Robocomp 2014 2. Robotic Tournament 2015 Konstrukcja mechaniczna Podwozie stanowi kawałek cienkiego laminatu, do którego przykręcone są silniki Pololu 30:1 wraz z enkoderami. Felgi od Solarbotics + odlane opony. Listwa czujników to Pololu QTR-8RC wysunięta na węglowej listewce. Elektronika Za zasilanie odpowiada pakiet Dualsky 7.4V, 150mAh. Jest on w zupełności wystarczający do robota bez turbiny. Sterownik silników to standardowo TB6612. Całość obsługiwana jest przez Arduino mini, czyli ATmega 328p. Do obniżenia napięć do wymaganych 5V służy stabilizator 7805. Napięcie silników nie jest w żaden sposób stabilizowane, więc obniża się wraz z rozładowywaniem pakietu. Dlatego trzeba go często doładowywać, żeby nastawy się nie rozjeżdżały. Oprogramowanie Program napisany w Arduino z użyciem biblioteki IRremote i QTR. Przed przejazdem odbywa się kalibracja czujników. Pilot służy tylko do załączania i wyłączania mostka. Podążanie za linią oparte jest na regulatorze PD. Zastosowanie takich, a nie innych podzespołów spowodowane było chęcią zrobienia w miarę lekkiego robota, z małą bezwładnością. Aktualnie jego waga to 97g. Filmik z jazd testowych
  38. 7 punktów
    Witam, pragnę zaprezentować serwomechanicznę ramię nad którym pracowałem przez jakiś czas, zdaje sobie sprawę iż nie jest doskonałe i wymaga jeszcze dopracowania wielu szczegółów, poniekąd jestem konstruktorem amatorem lecz to co robię sprawia mi wielką przyjemność i poczucie osiągania danego celu poprzez naukę, cierpliwość i wytrwałość Serworamię V.1.0. zbudowane jest na podstawie plastikowej obudowy w której zamieszczony jest transformator wraz z przetwornicą napięcia do której to przytwierdzone jest jedno z wielu serw mg995 towerPro dzięki temu obrot ramienia wynosi niemal 230 stopni :-> Wysięgnik ramienia oraz 2 moduł ramienia napędzany jest przez sprzężone serwa mg995 przez co siła uciągu jest podwójna - zapewnia to stabilność oraz znaczne zwiększenie siły wykonywanej pracy. Ostatni moduł ramienia oraz chwytak to spreparowane gotowe konstrukcje zakupione w sklepie botland również napędzane przez serwa mg995 Ogolnie całość napędza 7 serw mg995, zasilacz 150W/12V wraz z przetwornicą 300W step down nastawioną na 6V za bezpieczeństwem odpowiada moduł czujnika temperatury i wentylatora na przetwornicy który pokazuje aktualną temperaturę stabilizatora napięcia. Prąd jaki osiąga podczas pracy przy dużym oporze to blisko 8 Amper. Sterownik jaki zastosowałem obecnie to serwokontroler Polulu mini Maestro 12 kanałowy lecz nie jest on wystarczający do takich prac z powodu częstego "gubienia" zapisanych sekwencji pracy, przez co odtworzenie przynosi wiele uśmiechu myslę o zastosowaniu Arduino w celu tworzenia skryptu oraz przekaźników do zasilania serw - całość będzie bezpieczna, gdyż styki na mini maestro przy gniazdach GoldPin praktycznie się stopiły od prądu przez nie płynącego. z pewnościa konstrukcja wymaga poprawek i wielu modyfikacji, lecz sam nie ukrywam nie mam wystarczająco wiele czasu by działać z tym na bieżąco. zapraszam na film: (video od polowy filmu) __________ Komentarz dodany przez: Treker Następnym razem pamiętaj o dodaniu zdjęć o proporcjach ~3:2 w załączniku (jest one wyświetlane w katalogu robotów). Teraz poprawiłem to za Ciebie
  39. 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:
  40. 7 punktów
    Idąc za ciosem, tym razem chciałem przedstawić (najprawdopodobniej) pierwszego na tym forum robota klasy Ketchup House. W pracach nad jego stworzeniem brało udział 5 członków Koła Naukowego Robotyków. Nazwa Nazwa Pomidor wydaje się być dość zrozumiała z uwagi na nazwę konkurencji w której startuje, jednak numeracja już niekoniecznie Otóż bezpośrednim protoplastą tego robota jest robot Pomidor (1). Robot miał parę błędów konstrukcyjnych, które powodowały, że nie spisywał się najlepiej. W związku z tym podjęliśmy decyzję o zrobieniu dużo bardziej zaawansowanego robota – Pomidora 2. Jednak na jakiś czas przed zawodami stwierdziliśmy, że nie zdążymy wykonać go w wymarzonej przez nas formie, więc powstał robot będący hybrydą tych dwóch podejść – Pomidor 1.5. Konstrukcja okazała się na tyle udana, że na jej podstawie powstała kolejna generacja robota – Pomidor 1.6 (o której będzie zapewne w kolejnym poście). Zawody Ketchup House Ponieważ jest to dość egzotyczna kategoria (przynajmniej w Polsce), pozwolę sobie ją najpierw krótko opisać. Moim zdaniem, Ketchup House jest zdecydowanie najbardziej nieprzewidywalną i widowiskową konkurencją odbywającą się na zawodach konstruktorskich. W każdej, trwającej 3 minuty rozgrywce udział biorą 2 roboty. Polem ich zmagań jest biała, kwadratowa plansza o wymiarach min. 1,8x1,8m. Na planszy znajduje się 10 czarnych linii (5 poziomych i 5 pionowych) o szerokości 12mm, tworząc kwadrat o wymiarach 1,2x1,2m, podzielony na 16 mniejszych kwadratów o wymiarach 0,3x0,3m. Na skrzyżowaniach umieszczane są puszki z tytułowym keczupem. Są to typowe stalowe puszki o średnicy 53 mm, wysokości 74 mm i masie ok. 163 g. W każdej, trwającej 3 minuty potyczce biorą udział 2 roboty. Ich zadaniem jest przemieszczenie puszek na swoją linię „domową”. Na początku rozgrywki na planszy znajduje się 5 puszek. 2 z nich, zaznaczone na zielono, znajdują się w ustalonych pozycjach (skrzyżowania C2 oraz C4). Położenie 3 pozostałych puszek jest losowane tuż przed rozpoczęciem pojedynku. Aby zrównoważyć szanse robotów na zwycięstwo, każda z dolosowywanych puszek musi się znaleźć na innej z linii B, C, D. Na początku pojedynku roboty są umieszczane w pozycjach A3 oraz E3. Na znak sędziego roboty są uruchamiane. Od tej pory, aż do zakończenia pojedynku nie ma możliwości ingerencji w ich działanie. Jeżeli podczas rozgrywki robot poruszy jedną z puszek w wylosowanej pozycji, to na jej miejsce dostawiana jest kolejna. Dostawienie następuje po przejechaniu przez robota do następnego skrzyżowania. W trakcie jednego pojedynku na planszy może się pojawić łącznie do 12 puszek. Istnieje zupełna dowolność w sposobie przemieszczania i odstawiania puszek. Nie ma także ograniczeń co do sposobu poruszania się po planszy – roboty mogą poruszać się po wyznaczonych liniach, ale nie muszą. Przypadkowe zderzenia na ogół nie są karane, jednak niezgodne z zasadami jest zamierzone „dążenie do zderzenia” (np. wypychanie poza planszę). Roboty powinny wykrywać i omijać przeciwnika. Po upływie 3 minut następuje zakończenie potyczki. Roboty (jeżeli zachodzi taka potrzeba) są zatrzymywane. Za każdą puszkę dotykającą linii bazowej przyznawany jest 1 punkt. (Na rysunku poniżej przykładowa sytuacja na koniec pojedynku, zakończona wynikiem 5-4 na korzyść robota 2 (niebieskiego)). Mechanika Po tym dość przydługim wstępie, teraz parę słów o samej konstrukcji. Bazę robota stanowią dwie płyty laminatu szklano-epoksydowego. Obie płytki stanowią dwojaką rolę - po pierwsze są to bazowe komponenty, do których montowane są wszystkie pozostałe części, po drugie zaś - rozmieszczone są na nich wszystkie połączenia elektryczne. Obie płyty mają kształt prostokąta o wymiarach 200x190 mm, w którym wycięto V-kształtne wycięcie. Płyty są ze sobą skręcone za pomocą mosiężnych dystansów. Układ napędowy stanowią dwa silniki POLOLU z przekładnią 298:1. Wcześniej stosowaliśmy silniki o dużo mniejszym przełożeniu, jednak podczas naszych pierwszych zawodów okazało się, że jazda ze zbyt dużą prędkością jest nieopłacalna – podczas zderzeń sędzia zawsze uznawał, że to nasza wina, gdyż jechaliśmy z dużo wyższą prędkością (poza tym zastosowanie tak dużego przełożenia pozwoliło nam na uzyskanie większej dokładności enkoderów). Koła podporowe (Kastora) oraz koła napędowe także pochodzą od POLOLU – zostały wybrane głównie ze względu na odpowiedni rozmiar. Do unieruchamiania puszki wykorzystujemy ramkę napędzaną serwomechanizmem. Aby mieć możliwość dokładnego sterowania oraz monitoringu siły, zdecydowaliśmy się na Dynamixela AX-12A (duży wpływ na to miał także fakt, że akurat taki posiadaliśmy w schedzie po starszym projekcie ) Na zawodach zaobserwowaliśmy, że ze względu na wystające kółka czasami robotowi zdarza się zakleszczyć (np. o puszkę) aby uniknąć takich sytuacji wydrukowaliśmy osłonę okalającą całego robota. Elektronika Schemat ideowy całego układu elektronicznego można zobaczyć na rysunku poniżej: Mózgiem robota jest STM32F100RB, będący częścią zestawu STM32 Discovery VL. Zdecydowaliśmy się na takie rozwiązanie, aby móc podczas zawodów zmieniać szybko algorytm pomiędzy potyczkami i mieć możliwość jego szybkiego wymienienia w razie awarii. Jak można zaobserwować na rysunku robot jest wyposażony w dużą ilość czujników. Zdecydowanie najważniejszymi z punktu widzenia algorytmu sterowania są czujniki odbiciowe. Jest ich aż 17 (na dolnej płytce) ich rozmieszczenie można zaobserwować na rys. poniżej. Aby móc dopasowywać się do różnych plansz, układ wyposażono w komparatory oraz potencjometr, które pozwalają na ustawienie poziomu, od którego wykrywana jest czerń. KTiRy można przyporządkować do 3 grup. Czujniki oznaczone numerami 4-11, znajdujące się w przedniej części robota, są wykorzystywane w algorytmie jako źródło danych regulatora sterującego jazdą po prostych, a także (w mniejszym stopniu) do wspomagania obrotu. Czujniki w przednich rogach płytki (odpowiednio 11 i 12 oraz 13 i 14) były wykorzystywane przy dowożeniu puszek - do dokładnego pozycjonowania puszek na linii oraz jako czujniki awaryjne podczas jazdy po prostej. Transoptory po bokach (15, 16 i 17 oraz 18, 19 i 20) umożliwiają wykrycie dojazdu do skrzyżowania oraz są głównymi sensorami wykorzystywanymi w algorytmie obrotu. W toku testowania okazało się, że bardzo przydatne byłyby dodatkowe czujniki, które umożliwiłyby jazdę po linii do tyłu. Aby nie wytrawiać całej płytki od nowa, wykonano dodatkową tylną płytkę, na której znajdują się 3 czujniki (o numerach 1-3) Kolejnymi ważnymi czujnikami były enkodery. Na początku stosowaliśmy enkodery optoelektryczne, które do poprawnego działania wymagały zastosowania komparatorów oraz przejścia żmudnego procesu kalibracji (dla każdego z KTiRów z osobna dobieraliśmy nastawy potencjometru). Jednak gdy tylko pojawiły się enkodery magnetyczne dla silników POLOLU, nasze problemy odeszły do lamusa. (Dla porównania – sygnał z enkoderów optoelektrycznych oraz z magnetycznych) Poza tym stosowaliśmy czujniki odległości – do wykrywania puszki oraz do wykrywania przeciwników na planszy. Aby uniknąć cross-talku do jednego zadania wykorzystaliśmy analogowe czujniki SHARP (4-30) a do drugiego czujniki ultradźwiękowe. Aby ustawić odpowiedni kąt czujników ultradźwiękowych – tak, aby wykrywały jedynie przeciwnika, a nie puszkę, zaprojektowaliśmy specjalne mocowanie, umożliwiające modyfikację ich kąta nachylenia. Dla ciekawskich, poniżej są schematy: Na koniec, tradycyjnie, krótki filmik pokazujący działanie robota: [ Dodano: 28-03-2016, 22:01 ] Nie chcąc przedłużać i tak przydługiego już posta, o algorytmie będzie nieco więcej przy okazji opisu robota Pomidor 1.6.
  41. 7 punktów
    Witam. Nie było chyba na tym forum podobnej konstrukcji więc opiszę krótko efekt pracy "mojego zespołu". Mam nadzieję że moderator przepuści wątek z racji ciekawej konstrukcji mimo tego że wyszedł z tego pojazd zdalnie sterowany a nie robot. Założenia jak to zwykle u mnie - zabawka na pokazy. Trochę danych: Konstrukcja - frezowany laminat + elementy drukowane. Wszystko zaprojektowane przez współtwórcę w SW. Napęd - tanie żółte silniki z przekładniami z chin zamocowane w sposób sprężysty w konstrukcji. Koła - dekle wycięte laserem z aluminium, rolki wydrukowane + pokrycie rurką termokurczliwą. brak łożysk. Zasilanie - początkowo miały być koszyki na 6 paluszków ale start 4 silników powodował ogromne spadki więc wygrzebałem z gratów ogniwa od laptopa i podłączyłem jako 2s2p Elektronika - Arduino nano+najtańsze mostki z chin na L9110+sonar+odbiornik RC+BT Software - napisane w Arduino przez współtwórcę. Software na Smartfona - napisany po przeglądnięciu kursu na forbocie. Na chwilę obecną jest - Tryb demo - pojazd jakoś się tam porusza po kawałku w każdą stronę wracając do miejsca startu - Tryb RC - dzięki wbudowanemu odbiornikowi można go sterować z aparatury i jest to najfajniejszy tryb - Tryb z telefonu - możliwe jest sterowanie guzikami oraz wykorzystując akcelerometry położeniem telefonu - Tryb pomiaru odległości - odsyła na smartfona odległość od przeszkód. Chcieliśmy sonar wykorzystać podczas normalnej jazdy ale umieszczony w plastykowej obudowie czasami szaleje (bez obudowy działa dobrze) i nie chcieliśmy alby jego zwiecha zablokowała nam pojazd. Fajnie wszystko działa. Nawet lepiej niż zakładaliśmy. Spełnił nasz założenia choć oczywiście ma kupę wad. Największa to chińskie przekładnie. W tył kręcą inaczej niż w przód. Jedne startuje przy PWM=30% , inny przy PWM=50%. Dlatego kolega zaprogramował KickDown dającego kopniaka startującego silnik przy małym PWM. Nie polecam tych silników choć za 5zł nic lepszego nie znajdziemy z przekładnią. OK koniec pisania. Kilka fotek i filmik Pozdrawiam Sławek
  42. 6 punktów
    Swoją przygodę z elektroniką zacząłem kilka lat temu z celem zbudowania czworonożnego chodzącego robota. Nie bardzo sobie zdawałem wówczas sprawę ze stopnia skomplikowania tego zadania i śmieszy mnie dziś moja ówczesna naiwność, ale od tego czasu minęło parę lat i wiele się nauczyłem. W międzyczasie stworzyłem projekt taniego i łatwego w montażu robota, który opublikowałem pod adresem http://tote.rtfd.io, żeby nieco ułatwić zadanie innym. Naiwnie myślałem, że skoro dałem ludziom prosty punkt startowy, to teraz będą na jego bazie budować bardziej rozbudowane roboty i eksperymentować z platformą. Oczywiście myliłem się straszliwie, choć wiem o kilku konstrukcjach zainspirowanych moją. Dziś sam jestem dziadkiem^W^Wwiedząc więcej o tym jak to działa, postanowiłem zaprojektować zestaw do samodzielnego montażu oparty na podobnych pomysłach, ale bardziej mający formę gotowca. Zamiast optymalizować cenę postanowiłem tym razem zoptymalizować wygodę. Docelowo zamierzam zestaw sprzedawać częściowo zmontowany na Tindie. Dużo szczegółów konstrukcji pozostało z Tote. Nadal używam tanich serw SG90, które nadal zasilam bezpośrednio z baterii LiPo, kompensując za niskie napięcie większą częstotliwością sygnału sterującego. Nadal wykorzystuję fakt, że robot jest taki lekki, żeby przemycić nie do końca koszerne rozwiązania, jak wykorzystanie serw jako stawów nóg, bez dodatkowego podparcia, albo sklejanie ze sobą dwóch serw za pomocą hot glue. Ale tym razem nie używam taniego Arduino Pro Mini i C++, tylko mikrokontroler Atmel SAMD21 i CircuitPython. Nie ma już brzęczyka piezo na nóżce GPIO, tylko głośniczek podłączony do DAC. Do tego dodany jest akcelerometr dla prostego reagowania na ruszanie robotem i to tyle. Na górze jest header z nieużywanymi pinami do wpinania ewentualnych rozszerzeń — czujników lub dodatkowych serw czy światełek. Największą innowacją jest zrezygnowanie z użycia plastikowych orczyków od serw jako elementów konstrukcyjnych nóg, a zamiast tego płytka PCB zawiera, poza układem sterującym robota także wszystkie elementy mechaniczne. Sprawia to też, że łatwo możemy wymienić fragmenty nóg na inne, zawierające czujniki lub inne elementy elektroniczne. Programowanie, jak to w CircuitPythonie, odbywa się poprzez wgranie plików z kodem w Pythonie do robota, który po podłączeniu przez USB pojawia się w komputerze jako dysk. Możliwe też jest eksperymentowanie na żywo za pomocą konsoli pythonowej dostępnej po serialu. Robot jest pod względem mechanicznym w zasadzie ukończony, jak zwykle pozostaje jego zaprogramowanie, które pomimo wykorzystania języka wysokiego poziomu zajmuje mi sporo czasu — muszę się przyznać, że to nie ze względu na trudność problemu, ale na zmęczenie dzienną pracą i ciągłe odkładanie tego na później.
  43. 6 punktów
    Jak zbudować robota kroczącego? Na czym właściwie polega chodzenie? Jakie czujniki są do tego potrzebne? Na te pytania postaram się tutaj odpowiedzieć. Kroczenie a pełzanie Na początek zastanówmy się co tak naprawdę chcemy uzyskać. Aby zbudować urządzenie przemieszczające się bez kół nie potrzeba wiele — ot, dowolny mechaniczny aktuator wykonujący cykliczne ruchy może, na odpowiednim podłożu i przy odrobinie szczęścia, poruszać się jakimś mniej lub bardziej przewidywalnym kierunku. Istnieje nawet całkiem sporo publikacji naukowych o "robotach uczących się chodzić", w których te periodyczne ruchy są sterowane przez sieć neuronową lub inny ewoluujący element tak, aby zoptymalizować prędkość przemieszczania się. Ale ja osobiście nie nazwałbym tego chodzeniem, a już na pewno nie kroczeniem. Czego zatem wymagamy? Według mnie podstawowym i minimalnym wymaganiem jest to, aby żadna część robota nie była wleczona podczas przemieszczania się — aby tylko stopy dotykały podłogi i aby nie poruszały się względem tej podłogi przez cały czas gdy jej dotykają. Raz postawiona stopa musi pozostać w jednym miejscu aż nie zostanie ponownie podniesiona. W ten sposób gwarantujemy sobie dużą niezależność od rodzaju podłoża i minimalizujemy niszczenie jego oraz elementów go dotykających. Oczywiście w praktyce zawsze będą występować drobne ruchy: szpiczasta noga pająko-podobngo robota może, pozostając w miejscu, obracać się, a nawet stopa humanoida będzie się w momencie odbijania od ziemi lekko przesuwać. Ale wiemy już przynajmniej w którym kierunku chcemy... kroczyć. Kroczysz czy się toczysz? Drugim pytaniem, jakie musimy sobie zadać, jest jak dużo kontroli powinniśmy mieć nad ruchami nóg? Czy jeżeli z drewnianego koła od wozu drabiniastego zdejmę felgę i na odsłonięte tak drewniane szprychy pozakładam stare buty, to uzyskam urządzenie kroczące? Nasz pierwszy warunek jest w zasadzie spełniony — but raz postawiony na ziemi nie przesuwa się aż się od niej nie oderwie — jednak uzyskany sposób lokomocji niewiele różni się od zwykłego transportu kołowego, w szczególności dzieląc z nim problemy z radzeniem sobie z nierównym podłożem czy przeszkodami. To samo rozumowanie dotyczyć będzie wszelkiego rodzaju napędzanych jednym silnikiem mechanizmów takich jak Strandbeest czy Hexbugs. Jasne, wyglądają jakby miały nogi i chodziły, ale tak naprawdę są to tylko bardziej skomplikowane koła. W naszych robotach kroczących chcielibyśmy mieć kontrolę nad miejscem postawienia każdej nogi. Stopnie swobody Skoro jeden silnik to za mało, to w takim razie ile stopni swobody musi posiadać nasz robot żeby kroczyć? Powyższy warunek kontroli miejsca postawienia nogi daje nam minimalną granicę dwóch stopni swobody: poruszanie nogą i jej opuszczanie i podnoszenie. I rzeczywiście, można sobie wyobrazić robota składającego się z dwóch trójnogów przemieszczających się względem siebie w przód i w tył oraz w górę i w dół. W praktyce jednak najczęściej stosujemy konfiguracje wzorowane na zwierzętach, z osobnymi nogami o dwóch, trzech albo i więcej stopniach swobody. Niezależnie od konfiguracji, aby poruszać się w linii prostej nasz robot musi umieć podnieść i opuścić każdą z nóg, oraz przesunąć stojącą na ziemi nogę do tyłu wzdłuż linii prostej. Wymaga to dwóch stopni swobody, jeśli noga porusza się równolegle do ciała (jak u kota czy człowieka), lub trzech, jeśli noga porusza się po łuku (jak u pająka lub jaszczurki). Dodatkowo, niezbędne mogą być dodatkowe stopnie swobody jeśli noga posiada stopę, a także jeśli robot ma być w stanie wykonywać zakręty czy nawet obroty w miejscu. Należy się zatem przygotować na konieczność sterowania dużą liczbą aktuatorów (a także ich pozyskania i zasilania), co niestety często jest największą barierą przy budowanie takiego robota. Siła i masa Drugim, poza liczbą aktuatorów, wyzwaniem dla konstruktora robotów kroczących jest masa. Podobnie jak pojazdy latające, a w odróżnieniu od pojazdów kołowych i gąsienicowych, pojazd kroczący niesie własne ciało (plus ewentualny ładunek) siłą swoich silników. Istnieją co prawda bardzo wydajne chody pozwalające na odzyskiwanie i ponowne użycie znacznej porcji energii (ludzie właśnie taki chód stosują), ale są one na tyle zaawansowane, że nie mamy praktycznych systemów je wykorzystujących. Dla amatora-hobbysty pozostaje opcja niesienia całego robota energią baterii. Chcemy zatem, aby nasz robot był jak najlżejszy. Warto przy tym pamiętać o tak zwanym prawie sześcianów: przy zachowaniu wszystkiego innego, masa robota rośnie do sześcianu jego wielkości. Zatem jeśli robot wielkości 1m waży 10kg, to taki sam robot (tylko przeskalowany) o wielkości 2m ważyć będzie 80kg (możemy sobie wyobrazić 8 mniejszych robotów ustawionych w kostkę wewnątrz większego). Stwarza to wiele problemów, oczywiście, bo konstrukcja większego robota, przy użyciu tych samych materiałów, będzie tylko 4 razy mocniejsza, a silniki tylko dwa razy silniejsze. Na szczęście pojemność baterii także wzrośnie proporcjonalnie do sześcianu wielkości. Dlatego zdecydowanie łatwiej jest budować roboty o mniejszych wymiarach. Możemy sobie wówczas pozwolić na użycie tańszych i łatwiejszych w obróbce materiałów i słabszych silników. Oczywiście ograniczy to nam także wielkość i masę jednostki sterującej, ale przy postępującej miniaturyzacji jest to najmniej bolesne ograniczenie. Bardziej bolesne jest ograniczenie masy ładunku, którym nasz robot będzie w stanie manipulować — nie pojeździmy sobie na pająku. Jednak szczególnie dla początkujących zbudowanie małego robota będzie i łatwiejsze i bardziej praktyczne — łatwiej z nim eksperymentować i więcej się można nauczyć. Stabilność statyczna Dla uproszczenia zaczniemy od modelu, w którym nasz robot jest na tyle lekki i porusza się na tyle wolno, że siły bezwładności są pomijalnie małe i możemy je zignorować. W ten sposób z naszych obliczeń eliminujemy zmienną czasu i znacznie je upraszczamy. Dodatkowym ułatwieniem przy takim podejściu jest fakt, że nasz robot może się wtedy poruszać dowolnie wolno, a nawet w dowolnym momencie zatrzymać się bez przewracania. Oczywiście ogranicza to nas wtedy do statycznie stabilnych chodów, no ale od czegoś w końcu trzeba zacząć. W modelu bez inercji warunek stabilności robota jest bardzo prosty: obrysowujemy znajdujące się na ziemi stopy robota wypukłą obwiednią (czyli tak, jakbyśmy zrobili wokół nich pętlę ze sznurka i ją zacisnęli). Kształt, który uzyskamy nazywamy wielokątem podparcia. Jeśli stopy są szpiczaste, jak u insektów, to będą w narożnikach tego wielokąta. Jeśli mają inny kształt, to stanie się on częścią obrysu. Na przykład przy czworonożnym pająkopodobnym robocie i przy wszystkich nogach na ziemi, będziemy mieć czworokąt: A kiedy podniesiemy jedną nogę, uzyskamy trójkąt: Kiedy już mamy nasz wielokąt podparcia, to pozostaje nam znaleźć środek ciężkości naszego robota (uwaga — może się on zmieniać na skutek poruszania nóg czy innych elementów), poprowadzić z niego pionową kreskę aż do ziemi (zgodną z kierunkiem działania grawitacji) i sprawdzić, czy znajduje się ona wewnątrz naszego wielokąta. Jeśli tak, robot będzie stał. Jeśli nie, to znaczy że już się przewraca. Przy okazji, odległość tego punktu od najbliższego brzegu wielokąta podparcia jest dobrym wyznacznikiem stabilności robota — jego odporności na zewnętrzne siły. W przykładzie powyżej pionowy rzut środka ciężkości wypada dokładnie na brzegu trójkąta — zatem robot przewróci się od najdrobniejszego dotknięcia czy wibracji. Aby tego uniknąć, można przesunąć trzy nogi robota w kierunku tej, która ma zostać podniesiona zanim zaczniemy ją podnosić: To właśnie dlatego kroczące roboty często kiwają się na boki — przesuwają swój środek ciężkości, aby zawsze mieścił się w wielokącie podparcia. Stabilność dynamiczna Gdy chcemy, aby nasz robot poruszał się szybciej, a także potrafił chodzić z mniej niż trzema nogami na ziemi i bez rakiet śnieżnych, to musimy uwzględnić w naszych obliczeniach bezwładność. Jest wiele sposobów na zrobienie tego, ale niestety większość oznacza numeryczne rozwiązywanie skomplikowanych równań różniczkowych, co wymaga sporej mocy obliczeniowej. Istnieje jednak jedna dość prosta metoda nie wymagająca złożonych obliczeń, nazwana ZMP (zero-movement point). Czym jest ZMP? Pamiętacie ten punkt na ziemi bezpośrednio pod środkiem ciężkości robota? To właśnie jest ZMP w przypadku, kiedy inercja jest zerowa. W przypadku, gdy nie jest ona zerowa, punkt ten przesuwa się zgodnie z kierunkiem i siłą jej działania. Jest to po prostu punkt, w którym musielibyśmy się podeprzeć, żeby w danym momencie się nie przewrócić. Zatem wystarczy, że tak będziemy planować nasze ruchy, żeby ZMP nigdy nie znajdował się poza wielokątem podparcia na tyle długo, żeby robot się zdążył przewrócić, a wszystko będzie działać. No dobra, ale jak możemy wyznaczyć ZMP? Okazuje się, że jest na to kilka bardzo prostych sposobów. Jeśli mamy w stopach robota czujniki nacisku, to mierząc i uśredniając działające na nie siły jesteśmy w stanie wyznaczyć ZMP. Możemy też ZMP wyznaczyć przy pomocy akcelerometru, jeśli znamy środek ciężkość — wystarczy poprowadzić linię w kierunku wskazywanym przez niego, a tam gdzie przetnie podłogę będzie ZMP. Kinematyka odwrotna Aby mieć dobrą kontrolę nad tym co nasz robot robi i gdzie dokładnie stawia stopy, musimy opanować geometrię jego nóg i potrafić wyliczyć jak te nogi przesunąć żeby ustawiły się w danej pozycji. Takie obliczenia nazywane są kinematyką odwrotną i w przypadku nóg o dwóch lub trzech ortogonalnych stopniach swobody są relatywnie proste — wystarczy nam znajomość trygonometrii ze szkoły podstawowej. Cała sztuka sprowadza się do tego, aby współrzędne stopy móc przeliczyć na kąty w poszczególnych stawach nogi. Oczywiście dla każdej konfiguracji obliczenia będą inne, zatem nie będę się w nie tutaj bardzo zagłębiał. Oczywiście da się poradzić sobie z tym problemem bez obliczeń, po prostu zaszywając w programie poszczególne pozy naszego robota i przejścia między nimi. Niestety takie podejście nie pozwala nam modyfikować chodu w odpowiedzi na nierówny teren, dodatkowe siły, skręcanie czy zmianę pozycji ciała względem trasy — zatem daje naszemu robotowi niewiele przewagi nad zwykłym robotem na kołach. Układy współrzędnych Układ współrzędnych, w którym określana jest pozycja stopy względem ciała robota (a w zasadzie względem punktu przyczepienia nogi do tego ciała), to tylko początek. Oczywiście każda noga będzie miała swój. Ale jeśli chcemy naszego robota kontrolować jako całość (na przykład żeby przesuwać jego ciało celem odpowiedniego ustawiania środka ciężkości), to będziemy chcieli mieć drugi układ współrzędnych, wspólny dla wszystkich nóg — układ współrzędnych ciała. Następnie przydałoby się znać pozycję niejako środka robota, ignorującą przesunięcia ciała wynikające z balansowania i ruszania nogami — to, czym sterowalibyśmy przy pomocy zdalnego sterowania, na przykład. To układ współrzędnych wirtualnego pojazdu. No i wreszcie, jeśli nasz robot zapamiętuje mapę otoczenia, to wypadałoby mieć układ współrzędnych świata, w którym ten wirtualny pojazd się przesuwa. Przejścia pomiędzy tymi układami współrzędnych najłatwiej zrealizować poprzez mnożenie współrzędnych przez macierze przejścia pomiędzy bazami. W ten sposób trywialnie zaimplementujemy translację i rotację ciała robota. Chód Sam chód to prosta sprawa, choć oczywiście istnieje wiele wariacji na jego temat. Generalnie idea jest taka, że wszystkie nogi znajdujące się na ziemi przesuwają się do tyłu (najlepiej jednostajnie, choć można to też robić skokowo), a te najdalej wysunięte do tyłu są podnoszone i przestawiane do przodu kiedy tylko jest do tego okazja (na tyle szybko, żeby się nie skończył ich zakres ruchu do tyłu). W przypadku czworonogów istnieje optymalna kolejność takiego przestawiania (prawa-przednia, lewa-tylna, lewa-przednia, prawa-tylna) zapewniająca najlepszą stabilność, w przypadku dwunogów nie ma za bardzo wyboru, a sześcio-i-więcej-nogi mogą sobie pozwolić na dużo fantazji w tym zakresie. Statycznie stabilny chód u czworonogów jest jeden i nazywa się "creep" (skradanie się?) — polega na przestawianiu jednej nogi na raz. Gdy mamy stabilność dynamiczną, to możemy przejść do kłusu ("trot"), w którym przestawiamy dwie nogi na raz — po przekątnej, a nawet do galopu, w którym momentami tylko jedna noga dotyka ziemi (istnieją 4 wariacje tego chodu, w zależności od kolejności nóg). Jeśli mamy naprawdę szybki komputer i dobre czujniki (i silne aktuatory), to możemy nawet skakać... To tyle Tyle potrafię na ten temat napisać bez wchodzenia w szczegóły dotyczące konkretnych konfiguracji (humanoid, czworonóg, sześcionóg, etc.). Mam nadzieję, że jest to przynajmniej jakiś punkt startowy dla hobbystów projektujących swojego pierwszego robota kroczącego.
  44. 6 punktów
    Nie samą maliną człowiek żyje Już na samym początku wspominałem o tym, że Raspberry Pi nie jest wcale ani jedyną, najlepszą, ani najtańszą platformą sprzętową dla wbudowanego Linux-a. Jej ogromnym plusem jest bardzo dobre wsparcie, ale nic nie stoi na przeszkodzie w używaniu innych płytek. I tutaj ważna uwaga - w bardzo podobny sposób możemy łatwo przygotować obraz systemu również dla innych platform. Yocto wykorzystuje tzw. warstwy - są to zestawy gotowych skryptów, jak dla mnie to takie moduły, czy biblioteki, ale ktoś wymyślił określenie warstwa więc będę się tego trzymać. W internecie znajdziemy całkiem sporo gotowych warstw, wiele osób przygotowuje własne - my też możemy, chociaż to chyba trochę bardziej zaawansowany temat. Co ważne warstwy pozwalają na oddzielenie części sprzętowej (BSP - Board Support Package) od reszty systemu. Więc zmieniając warstwę meta-raspberrypi na inną dostaniemy taki sam system (tzn. z takimi samymi pakietami), ale działający na innej platformie. Jakie platformy są wspierane? W sumie to prawie wszystkie - najlepiej do znajdowania warstw użyć wyszukiwarki: http://layers.openembedded.org/layerindex/branch/sumo/layers/ Wspomnę o kilku platformach, które moim zdaniem są warte uwagi: BeagleBone - jest domyślnie wspierana przez Yocto i włączona do dystrybucji Odroid (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-odroid/) - często wymieniane jako konkurencja malinki, na ogół wydajniejsze niż oryginał Xilinx (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-xilinx/) - tutaj znajdziemy wsparcie dla układów Zynq, czyli FPGA z Cortex-A9 Freescale (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-freescale/) - bardzo fajne procesory i płytki, trochę droższe ale z lepszą dokumentacją Intel (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-intel/) - yocto może też przygotować dystrybucję dla x86. Stary komputer może odzyskać drugą młodość jeśli potraktujemy go jako urządzenie wbudowane. Poza tym są wszystkie LattePanda i podobne (był też Edison, ale to już historia) Tegra (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-tegra/) - coś dla miłośników szybkich maszyn oraz GPU (albo hackerów Nintendo Switch) W nieco starszej wersji yocto mamy jeszcze większy wybór: Altera (http://layers.openembedded.org/layerindex/branch/rocko/layer/meta-altera/) - układy z FPGA oraz Cortex-A9, odpowiednik Zynq od Xilinx-a. Właśnie tej warstwy używałem przygotowując oprogramowanie dla mojego wyświetlacza paneli LED (https://forbot.pl/forum/topic/12015-wyswietlacz-z-paneli-led/) AllWinner (http://layers.openembedded.org/layerindex/branch/rocko/layer/meta-sunxi/) - to coś dla miłośników tańszych układów, znajdziemy je na wszelkiej maści OrangePi, BananaPi, NanoPi oraz Olinuxino Jeśli będzie zainteresowanie tematem Yocto, postaram się opisać nieco dokładniej możliwości jego wykorzystania z Raspberry Pi - ale większość omawianych możliwości można wykorzystać na innych platformach.
  45. 6 punktów
    Pojawiają się tutaj co jakiś czas dyskusje o kosztach naszego hobby i o porównywaniu cen w różnych sytuacjach. Sam ostatnio zacząłem sprzedawać swoje projekty na Tindie, więc postanowiłem napisać artykuł wyjaśniający dlaczego rzeczy nowe, niszowe i robione przez hobbystów są takie drogie, podczas gdy takie Raspberry Pi Zero można kupić za 50zł (i dwa razy tyle kosztu wysyłki). Przy okazji być może wyjaśni to też dlaczego tak wiele kickstarterów się nie udaje. Różnica pomiędzy projektem a produktem Większość z nas ma już jakieś tam doświadczenie w realizowaniu projektów elektronicznych. Wymyśliliśmy (lub skopiowaliśmy z noty katalogowej) schemat, zaprojektowaliśmy płytkę, wytrawiliśmy ją, zamówiliśmy próbki części, zlutowaliśmy wszystko, zaprogramowaliśmy, zdebugowaliśmy, pięknie nam działa, koniec. Czas otwierać szampana i zakładać stronę na kickstarterze, już wkrótce wszyscy hobbyści będą mogli korzystać z naszego wspaniałego nowego produktu, który kosztował nas dużo mniej niż podobne produkty dostępne w sklepach, a przecież wyprodukowaliśmy tylko jedną sztukę -- w masowej produkcji powinno być jeszcze tańsze, prawda? Tak właśnie miałem z moim shieldem. Udało mi się gdzieś kupić okazyjnie matryce ledowe, które wielkością pasują idealnie do D1 Mini i aż się proszą o shielda. Napisałem też ostatnio bilbiotekę do obsługi HT16K33, który bardzo łatwo taką macierzą steruje. Tylko dodać dwa oporniki do I2C i gotowe. Będę to sprzedawał za dolara od sztuki. Kilka miesięcy i 5 prototypów później już nie byłem taki pewien. Oczywiście, błędy, które popełniałem były głupie i wynikały z roztargnienia i zbyt dużej pewności siebie. W końcu to taki prosty projekt. Mimo to czas mija, części na kolejne prototypy kosztują. Kilka razy projekt porzuciłem, ale jakoś zawsze jednak do niego wracałem. W końcu na początku roku uzyskałem coś, z czego byłem w miarę zadowolony. (Muszę tu przyznać, że projekt rzeczywiście był wyjątkowo pechowy, no ale nie kontrolujemy tego i nigdy nie możemy zakładać, że wszystko się uda.) No dobra, to teraz czas rozpocząć produkcję "masową". Powiedzmy 40 sztuk -- powinno się sprzedać błyskawicznie, jak tylko ludzie to zobaczą, to na pewno się rzucą i wtedy będę mógł zrobić kolejną partię, 400 albo i 4000 sztuk. No dobra, to gdzie najlepiej zrobić 40 płytek? Zdecydowałem się na DirtyPCB z ich ofertą 10 (+/-1) płytek o wymiarach 5x5cm -- bo udało mi się wcisnąć w tym obszarze cztery swoje płytki, a pozwalają na panelizację. Poprawiłem kilka detali, wcisnąłem po 4 płytki w jeden gerber, zamówiłem. Miesiąc później nadal czekam na płytki -- piszę do nich o co chodzi, zawsze płytki w 2 tygodnie były -- a oni mi odpisują, że mają dużą kolejkę po chińskim nowym roku, do tego musieli zmienić wykonawcę, etc. Acha, jako bonus, zmienili ostatnio wygląd strony i od tego czasu nie pokazuje się obrys płytki na podglądzie. Niby drobiazg, ale będzie to istotne później. W międzyczasie zamówiłem macierze i czipy. Płytki są małe, więc użyłem w nich najmniejszej wersji HT16K33, z minimalną liczbą nóżek. Okazuje się, że trudno znaleźć je w większych ilościach i są droższe. No trudno, kilka centów na czipie mnie nie zbawi, a płytki już zamówiłem. No to teraz macierze. Okazuje się, że są dwa rodzaje -- ze wspólna anodą i ze wspólną katodą. Oczywiście w przypadku macierzy 8x8 nie ma tu absolutnie żadnej różnicy, bo obie wersje mają po prostu LED-y podłączone do kolumn i wierszy, ale różnią się one wyprowadzeniami. Zatem należy uważać co się zamawia -- oczywiście najtańsze oferty nie mają w opisie informacji o tym jakie mają wyprowadzania albo jakiego są typu -- nie będę ryzykować kupowania 40 macierzy, które się potem okażą złe. Zatem trzeba wziąć te droższe. Zazwyczaj są w paczkach po 10 sztuk, więc sobie wymyśliłem, że zamówię różne kolory i ludzie będą sobie mogli wybrać. Doskonale, ale wszystko, co nie jest czerwone, jest dwa razy droższe. No trudno. To pewnie w ramach promowania komunizmu. Wysyłka na szczęście darmowa, zamówione. Mniej więcej dwa tygodnie po tych zamówieniach, pracując nad innymi projektami zorientowałem się, że co prawda mam zapas oporników, ale nie aż tyle, żeby zmontować te wszystkie macierze. No to jeszcze zamówiłem oporniki, 500 sztuk na zapas. Przyszły macierze. Zamawiając nie zauważyłem, że wszystkie są od tego samego sprzedawcy, więc przyszły w jednej paczce, która przez to przekroczyła próg cła i dopłaciłem drugie tyle za cło (tu gdzie mieszkam płaci się cło i "opłatę manipulacyjną" za to, że sprawdzili co to jest i oclili, która wynosi często więcej niż samo cło). Kolejna kosztowna pomyłka. W tym momencie już wiedziałem, że za dolara ich sprzedawać nie będę. Przyszły w końcu płytki. Okazało się, że zrobiłem błąd w projekcie i otwór na środku płytki, który powinien rozdzielać panele, nie jest wycięty. Oczywiście zemścił się brak podglądu, ale ostatecznie to moja wina. Dwa dni zajęło mi powycinanie 40 płytek dremelem. To teraz składanie. Najpierw polutowałem do wszystkich płytek oporniki i czipy. Oczywiście przez nieuwagę na dwóch płytkach czipy przylutowałem odwrotnie. Pojawiły się pierwsze zamówienia. Polutowałem do końca zamówione egzemplarze, przetestowałem czy działają i... jak ja mam to wysłać? Potrzebuję kopert bąbelkowych. W domu znalazłem dwie, na razie wystarczy, ale trzeba kupić więcej. Poszedłem na pocztę, popatrzyłem na ceny kopert i stwierdziłem, że zamówię je z Chin. No ale trzeba najpierw wysłać zamówienia. Ustalając ceny sprawdziłem koszty wysyłki na stronie poczty, więc teraz całkiem pewnie podaje pani w okienku koperty i mówię, że chcę to wysłać. Pani mierzy grubość i mówi, że musi wysłać jako paczkę, cztery razy drożej. No trudno, płacę i wracam do domu. Zamówiłem koperty (oczywiście dziesięć razy taniej niż na poczcie) i dodałem do strony produktu informację o tym, że wysyłam z nieprzylutowanymi nóżkami, bo inaczej się nie mieści do koperty. Biorę się za lutowanie pozostałych macierzy. Polutowałem wszystkie kolory i zabieram się za sprawdzanie -- zrobiłem sobie testing rig, tak że dość prosto mogę podłączyć i odpalić prosty program zapalający wszystkie piksele. Wszystkie niebieskie sprawne. Wszystkie czerwone sprawne, tylko w jednym miejscu mostek z cyny do usunięcia. Sprawdzam białe -- sprawna co druga. Hmm. Patrzę na kilka macierzy, które mi zostało -- oczywiście oznaczenia góra/dół mają całkowicie losowo -- a to według nich je lutowałem. Odlutować tego teraz już nie ma jak, połowa do wyrzucenia. Przyszły koperty, pojawiło się więcej zamówień. Skończyły mi się piny -- używałem tych, które miałem w zapasie -- trzeba zamówić. Kończy mi się rolka cyny, grot lutownicy zaczyna wykazywać oznaki zużycia. Moja lutownica jest markowa i droga i takież są też do niej groty. Wysyłam to, co mam zrobione aż się nie skończą -- średnio 1-2 zamówienia tygodniowo. Więcej nie będę raczej tego robić. Wszystkie projekty udostępniłem na otwartej licencji -- może jakiś Chinczyk to weźmie i zacznie produkować taniej i z darmową wysyłką. Koniec końców, wyszło około $5 za sztukę, z około $2 za wysyłkę do tego. Czyli siedem razy więcej, niż szacowałem. Oczywiście nie wliczyłem w cenę własnej robocizny -- ani godzin spędzonych na projektowaniu i testowaniu, ani na składaniu tego, ani na bieganiu na pocztę i wysyłaniu. Siedzę i czekam aż płytki dotrą do klientów -- i boję się, że coś będzie nie tak i trzeba będzie oddawać im kasę albo wysyłać nowe. Duży może więcej No dobra, to jakim cudem możemy kupować te płytki za $2 z darmową wysyłką? Dlaczego chińscy producenci nie mają takich problemów? Powodów jest kilka: Po pierwsze, mają subsydiowaną przez rząd darmową wysyłkę i wszystkie części dostępne na miejscu bez cła. Mogą kupować te najtańsze części bez dokumentacji, bo po prostu sobie sprawdzą czy wyprowadzenia są dobre. Po drugie, produkują w naprawdę gigantycznych ilościach i mają hurtowe ceny. Dodatkowo potrafią wynegocjować sobie naprawdę dobre warunki. Po trzecie, nie robią w zasadzie żadnej kontroli jakości. To jest krok, który u mnie okazał się najbardziej kosztowny -- nie dlatego, że był czasochłonny, choć był, ale dlatego, że wadliwych produktów nie sprzedam -- a Chińczyk by sprzedał. Po czwarte, mają naprawdę dobrze ogarnięty cały proces, wszystko przygotowane z góry, robili to już wiele razy, więc wiedzą czego się spodziewać. U mnie wiele kosztów wynikało z tego, że coś przegapiłem albo zapomniałem -- tam, nawet jeśli coś takiego się na początku zdarzy, to te koszty znikną przy takiej skali. Po piąte, nie mają kosztów projektowania, bo to są w większości otwarte projekty, które ktoś już im zaprojektował. Nawet jeśli musi na to spojrzeć specjalista, to znowu koszt jego pensji znika przy tej skali. Czyli kupować tylko od Chińczyka? Z ekonomicznego punktu widzenia, wydaje się to logiczną decyzją -- w końcu pieniądze nie rosną na drzewach. Najlepiej więc projektować wszystko tak, żeby używało tanich chińskich modułów? Taka taktyka działa dobrze na krótką metę. Jednak jest jeden podstawowy problem -- oni rzadko projektują coś nowego, nawet kiedy to robią, to nie jest to zbyt długo wspierane. W tym samym czasie technika galopuje do przodu i pojawiają się nowe rozwiązania. Potrzebujemy nowych projektów i potrzebujemy społeczności wokół nich, które będą je wspierać. Zatem być może jednak warto kupić czasem taki "przedrożony" nowy produkt -- w ramach inwestycji na przyszłość.
  46. 6 punktów
    W tym tygodniu mam dużo pracy i jeszcze nie udało mi się usiąść do myszy, ale ostatnio zdefiniowałem sobie problem przyspieszenia i dzisiaj zupełnie przypadkiem zapaliła mi się lampka w głowie: przyczepność i wynikający stąd poślizg to sprawa wtórna. To co istotne to II zasada dynamiki: F=m*a Czyli możliwości przyspieszania myszy zależą głównie od jej bezwładności (masy) i siły, czyli momentu silnika dzielonego przez promień koła. Żeby nie mielić na pusto wzorów, spróbujmy policzyć jaki moment powinien mieć silnik napędowy dla zadanego przyspieszenia, albo może lepiej z jakim przyspieszeniem mogę próbować rozpędzać mysz obecnym napędem. Moja mysz bez zasilania waży równiutko 100 g. Na razie jeżdżę z ciężkim pakietem 1600mAh o masie 102 g. Docelowo pakiet, powiedzmy 180mAh waży 20 g. Masa obecna to 202 g, docelowa120 g. Teraz siła. Silnik Pololu z przekładnią 10:1 ma moment 0,029 Nm. Średnica koła to 42 mm, stąd promień to 21 mm. Tak więc maksymalna siła na jednym kole przy pełnym wysterowaniu silnika to: F = M / r = 0,029 / 0,021 = 1,38 N Silniki są 2 więc mamy łączna siłę 2,76 N. Do tego dojdzie tarcie kulki podporowej, więc zaokrąglam siłę do 2,5 N. Teraz przyspieszenie dla obecnego i docelowego rozwiązania. a = F / m a1 = 2,5 / (9,81*0,202) = 1,26 m/s^2 a2 = 2,5 / (9,81*0,120) = 2,12 m/s^2 Gdybym zmienił przekładnię na 30:1 o momencie 0,059 Nm, to miałbym siłę na kole 2,8 N i łączną powiedzmy 5,4 N. Przyspieszenia to odpowiednio 2,73 m/s^2 oraz docelowo 4,59 m/s^2. Tutaj czuć ogień! Dla kompletu informacji warto podać jeszcze prędkości postępowe obu porównywanych napędów: P10:1 ma prędkość obrotową 3000 obr/min => 50 obr/s, więc prędkość liniowa to obrotowa razy obwód: 50 * 2 * Pi * 0,021 = 6,6 m/s P30:1 ma prędkość obrotową 1000 obr/min => 16,67 obr/s, więc prędkość liniowa to obrotowa razy obwód: 16,67 * 2 * Pi * 0,021 = 2,2 m/s Celem konkurencji jest najkrótsza eksploracja i najszybszy przejazd. Zakładając że eksploracja pozwala na jazdę komórka po komórce, więc robot musi rozpędzić się przez połowę komórki a w drugiej części hamować. Mając przyspieszenie i drogę można policzyć czas przejechania komórki dla obu napędów (10:1 i 30:1): t = sqrt( l / a) t10 = sqrt(0,18 / 2,12) = 0,29 s t30 = sqrt(0,18 / 4,59) = 0,20 s Tutaj widać że trzydziestka bije na głowę dziesiątkę. Szybkość przejazdu to trochę bardziej skomplikowana sprawa. Zróbmy to na jakimś przykładzie, tak aby przyjąć ilość odcinków o zadanej długości, np taki labirynt: ma 12 przejazdów po 1 komórce 3 po 2 komórki 4 po 3 5 po 4 2 po 5 1 po 11 komórek 1 po 12 komórek. Teraz trzeba wyliczyć jaki odcinek potrzebny jest do rozpędzenia się do maksymalnej prędkości. Wychodzę ze wzoru na czas rozpędzania do Vmax: t = v / a t10 = 6,6 / 2,12 = 3,11 s t30 = 2,2 / 4,59 = 0,47 s dochodzę do wzoru na drogę jaką pokona rozpędzając się do Vmax l = a * t^2 l10 = 2,12 * 3,11^2 = 20,5 m l30 = 4,59 * 0,47^2 = 1,01 m Już bez większego liczenia widać że napęd 10:1 aby się rozbujać potrzebuje 20 m i zupełnie nie nadaje się do tego typu robota. Napęd 30:1 rozpędzi się na maksa na drodze 6 komórek labiryntu i drugie 6 będzie hamował, więc w tym labiryncie tylko w jednym przejeździe przez chwilę osiągniemy maksymalną prędkość. To pokazuje że warto rozważyć nawet jeszcze wolniejszy napęd dający jeszcze większe przyspieszenie. W międzyczasie zrobiłem arkusz kalkulacyjny do przeliczenia 4 napędów: 10:1, 30:1, 50:1 i 100:1. Odcinki labiryntu podzieliłem na część w której robot się rozpedza i część z jaką jedzie z maksymalną prędkością. Policzyłem czasy pokonywania drogi przyspieszając, czas jazdy z maksymalną prędkością i łączny czas jazdy. Wyszło mi coś takiego: 10:1 = 6,59 + 0 = 6,59 s 30:1 = 4,6 + 0,06 = 4,66 s 50:1 = 2,77 + 4,01 = 6,77 s 100:1 = 0,73 + 18,97 = 19,7 s Wyniki oczywiście będą się zmieniały w zależności od masy i drogi labiryntu, ale dla zastałych warunków wyraźnie widać, który napęd jest optymalny.
  47. 6 punktów
    Witam! Photon Interceptor to mój pierwszy robot z którym pojawiłem się ostatnio na Robotic Arena 2014. Nie jest to demon prędkości a konstrukcja została stworzona z myślą o poszerzeniu wiedzy i umiejętności z zakresu programowania mikro klocków oraz zabawy z różnymi peryferiami. ELEKTRONIKA Projekt składa się z 3 płytek PCB zaprojektowanych w CadSoft EAGLE: Płyta główna - konstrukcja oparta jest na 8 bitowym mikroprocesorze Microchip PIC16F887 taktowanym zegarem o częstotliwości 20MHz. Za starowanie silnikami odpowiadają 2 mostki Texas Instruments L293DNE z połączonymi kanałami - 1 układ na jeden silnik, zasilane ze stabilistora ST L7806CV-DG - 1.5A. Wejścia EN są podłączone do pinów CCP mikroprocesora i sterowane poprzez PWM. Napięcie 5V dla logiki zapewnia stabilizator Texas Instruments LM2940 CT5.0. Z przodu płytki jest złącze dla ultradźwiękowego czujnika odległości HC-SR04, pod spodem zostało wyprowadzonych 8 wejść ADC mikroprocesora. W tylnej części znajduje się ekran LCD Raystar Optronics RC0802A-TIY-CSV 2x8 znaków podłączony do PICa poprzez 4 bitowy interface oraz złącze ICSP do podłączenia PICkita. Na płytce znalazły się również 2 przyciski - jeden został użyty do wykonywania kalibracji czujników przed przejazdem, drugi służy jako przycisk start. Po bokach procesora występują 2 złącza (podłączenie płytki komunikacyjno-wizualnej): na jednym zostało wyprowadzone SPI, EUSART oraz pozostałe 2 wolne piny, na drugim wyprowadzone jest GND i 5V. PCB - grubość 1.6mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. Płytka komunikacyjno-wizualna - część wizualna składa się z 8 diod LED RGB podłączonych do 3 rejestrów przesuwnych NXP 74HC595D które komunikują się z procesorem poprzez SPI. W części wizualnej znajdziemy moduł bluetooth Microchip RN4020 podłączony do EUSARTa poprzez konwerter poziomów oparty na tranzystorach BSS138 i zasilany ze stabilizatora 3.3V Microchip MCP1825S-3302E/DB. Dodatkowo w projekcie jest możliwość odbioru sygnałów z pilotów podczerwieni 36kHz poprzez odbiornik Vishay TSOP34836. PCB - grubość 1.2mm, pokrycie ENIG, grubość miedzi 35um. Płytka czujników - mamy tu możliwość podłączenia 13 czujników na 7 liniach - Knightbright KTIS0711S, niestety popełniłem mały błąd tworząc bibliotekę do KTIRa i mam źle umiejscowione pady :/ więc była zabawa z lutowaniem i nie testowałem innego rozmieszczenia czujników niż linia prosta. PCB - grubość 0.8mm, pokrycie HASL, grubość miedzi 35um. MECHANIKA Napęd robota składa się z silników Pololu 50:1 MP podłączonych do kół Solarbotics. W przedniej części znajduje się ballcaster Pololu 1/2". Rama robota została zaprojektowana w AutoCAD 2014 i wydrukowana na drukarce 3d w czarnym PLA. Użyta bateria LiPol to Redox 500mA. OPROGRAMOWANIE Program do mikroprocesora został napisany w języku C w środowisku MPLABX z wykorzystaniem kompilatora XC8. Filmik prezentujący przejazd robota w strefie serwisowej Robotic Arena 2014 - KLIKNIJ Pliki źródłowe, schematy itp udostępnię dopiero po świętach - mam jeszcze trochę kodu do napisania (bluetooth, podczerwień) i muszę poprawić algorytm jazdy LFa gdyż był klepany w nocy przed RA i w trakcie zawodów.
  48. 6 punktów
    Marku jest okazja to mogę powiedzieć że na tym forum jesteś moim wielkim autorytetem i chwała ci za to!
  49. 6 punktów
    Wstęp MicroMamut to nasz drugi robot. Tym razem postawiliśmy na kategorie MicroSumo. Założenia dla robota były takie by był w miarę szybki i oparty o czujniki Sharpa GP2Y0D340K. Jest to pierwszy nasz robot z elektroniką zbudowaną w technologii SMD. Najwiekszym wyzwaniem dla robota było zmieszczenie wszystkich elementów w ramach wymiarów 5x5x5 cm. Robot został złożony na 3 godziny przez zawodami Robotic Arena 2013, ale od razu zajął tam 3cie miejsce. Później na większości zawodów, na których startował też plasował się na podium. Lista sukcesów w sezonie 2013/2014: III miejsce na Robotic Arena 2013 II miejsce na T-BOT 2014 I miejsce na Robomaticon 2014 II miejsce na ROBO~motion 2014 I miejsce na ROBOXY 2014 Projektowanie Robot został zaprojektowany przy pomocy programu SketchUP. Dzięki wykorzystaniu tego programu udało się w miarę wszystko upakować zgodnie z zamierzeniami. Dodatkowo obudowa zaprojektowana w programie została wydrukowana na drukarce 3D co przyspieszyło prace. Schemat i płyki Robot ma trzy płytki które poza miescem na elektronikę stanowią także poziome elementy konstrukcyjne robota. Dolna płytka jest podstawą robota do której przytwierdzone są silniki. Dodatkowo przylutowane są do niej czujniki linii. Połączona jest ona kablami z górną płytką. Średnia płytka jest podstawą dla akmulatorów. Zawiera ona stabilizator liniowy oraz mostek H. Jest połączona kablami z płytą górną. Górna płytka jest płytką, na której znajduje się procesor. Zbiera ona sygnały z pozostałych płytek oraz z czujników. Znajdują się też na niej diody oraz są do niej przytwierdzone moduł startowy oraz przyciski. Dodatkowo ma ona wyprowadzone złącze programatora oraz układu debugu przez RS-232. Projekt schematu i płytki zostały wykonane w Eaglu. Płytki zostały wykonane na zlecenie. Elektronika Podstawowe elementy wykorzystane w układzie to: 1. Procesor Atmega 16 - sterowanie całym robotem 2. 3 czujniki 40 cm Sharp GP2Y0D340K - czujniki przeciwnika, jeden patrzący na wprost i dwa ustawione pod kątem 30 st. 3. 3 czujniki linii - KTIR0711S - do wykrywania linii oczywiście. 4. TB6612- dwukanałowy mostek H dla silników, sterowany sygnałami PWM z procesora 5. Stabilizator napięcia lm1117 dla zapewnienia 5V zasilania dla układów. Generalnie elektronika spełnia dobrze swoje zadania, dzięki zastosowaniu technologii powierzchniowej udało się zaoszczędzić dość dużo miejsca. Zasilanie Zdecydowaliśmy się na zasilanie 7,4V z dwóch cel. Aby odpowiednio upakować układy i dobrze rozłożyć ciężar wykorzystaliśmy dwa ogniwa jednocelowe z których poprzez odpowiednie połączenie został stworzony pakiet dwucelowy. Mechanika Jak wspomniano wcześniej podstawa robota to dolna płytka elektroniczna. Silniki to kultowe Pololu 30:1. Ponieważ są one dosyć dużo i nie mieszczą się w jednej osi na szerokość, trzeba było znaleźć sposób na odpowiednie ich ułożenie. Zdecydowaliśmy się na ułożenie silników jeden za drugim i przekazanie napędu jednego z nich na oś za pomocą kół zębatych. Było to trudne technicznie ale zapewnia dobre właściwości jezdne robota. Koła zostały odlane z silikonu. Wszystkie płytki elektroniczne połączone są przewodami na stałe. Rezygnacja ze złącz to duża oszczędność miejsca, utrudnia to jednak mocno prace konserwujące robota. Obudowa została wykonana w technologii druku 3D, i ze względu na dostęp do robota jest sklejona taśmą klejącą zamiast klejem. Przednia obudowa pełni funkcję "noża", nie jest ona jednak w tym zbyt efektywna. Robot dociążony jest odważnikami z ołowiu zaprojektowanymi w 3D i odlewanymi specjalnie dla niego, oraz dodatkowo dwoma odważnikami stalowymi na przedniej obudowie. Pomimo tego ma tendencje do przewracania się na tył. W maju 2014 robot przeszedł gruntowny przegląd, i zostały wymienione przewody wewnętrzne które powodowały czasami przerwy w działaniu. Problemy były związane bardzo krótkim czasem budowy, ale zostały już rozwiązane. Program Początkowo program był bardzo prosty. Na przełomie 2013 i 2014 program został przepisany na nowszy, bardziej czytelny i dający większe możliwości rozwoju. Obydwa programy bazują na programie z robota FlyingMamut. Program stworzony jest w oparciu o konkretne reguły odpowiadające staną czujników oraz stanowi logiki. Na podstawie stanu czujników i stanu obecnego ustalany jest stan następny. Program został napisany w języku C. Używałem WinAVR. Programuję przez USBAsp. Do debugowania programu używam złącza RS-232, którego moduł z układem MAX232 podpisany jest dodatkowo do robota. Podsumowanie Robot jest kolejnym etapem w naszej przygodzie z robotami sumo. Tym razem podeszliśmy do tematu już bardziej profesjonalnie i korzystaliśmy z projektowania 3D oraz technologii SMD. Robot świetnie spisywał się przez cały sezon 2013/2014, choć pod koniec sezonu zaczął już częściej przegrywać z innymi konstrukcjami. Zaletami robota jest jego szybkość oraz dobre czujniki. Wadami są złe rozłożenie wagi oraz brak noża. Robot po małych ulepszeniach będzie startował dalej ponieważ ma jeszcze potencjał. W planie jest kolejna konstrukcja microsumo bazująca na doświadczeniach z tego robota.
  50. 6 punktów
    Witam. Chciałbym Wam przedstawić mojego najnowszego robota klasy Line Follower Standard o nazwie "Pionier". Po raz pierwszy robot zaprezentował się na zawodach Robomaticon 2014 w Warszawie. Jest to moja druga konstrukcja tego typu. Konstrukcja mechaniczna Robot składa się z dwóch modułów: płytki z czujnikami oraz modułu głównego. Obie płytki w całości zostały wykonane przeze mnie. Oba moduły zostały połączone dwiema cienkimi listewkami z wytrawionego laminatu o grubości 1.6 mm. Koła jakie używam to standardowe koła Pololu oraz koła Solarbotics. Całość wraz z akumulatorem i kołami waży 137g. Średnia prędkość robota to 1 - 2 m/s w zależności od trasy. Moduł z czujnikami Starałem się by masa modułu była możliwie jak najmniejsza. Płytka została wykonana z laminatu o grubości 1 mm. Wymiary płytki to: 160 mm x 15 mm. W module zastosowałem 19 czujników KTIR ułożonych w łuk. Na płytce zostało umieszczone złącze dla cyfrowego czujnika odległości Sharp 40 cm. Moduł z czujnikami jest połączony z modułem głównym za pomocą złącz ZIF i taśmą FFC. Moduł główny Moduł główny jest podwoziem konstrukcji. Oprócz układów elektronicznych umieściłem na nim silniki napędowe, którymi są dwa silniki Pololu 10:1 HP. Podwozie zostało wykonane z laminatu o grubości 1.6 mm. Wymiary płytki: 130 mm x 60 mm. Elektronika Sercem robota jest mikrokontroler Atmega128. Procesor jest odpowiedzialny za odczyt stanów z czujników, realizację algorytmu i sterowaniem mostkami. Silnikami sterują dwa mostki H TB6612. Kanały w mostku zostały połączone dzięki czemu wzrosła wydajność prądowa mostka. Z innych elementów na płytce znajdują się: złącze programatora, wyprowadzenia do interfejsu USART, odbiornik podczerwieni TSOP2236, 2 przyciski, 4 diody led oraz kwarc 16 MHz. Zostały też wyprowadzane piny na enkodery magnetyczne AS5304, które zamierzam zamontować. Całość zasilana jest z pakietu Li-Pol Redox 3S 11.1V. Pakiet zamocowany jest na rzepy dzięki czemu nie ma problemów z jego wyjęciem, np. do ładowania. Zasilanie z Li-Pola trafia na dwa stabilizatory. Jeden z nich to stabilizator regulowany LM338T o wydajności 5A odpowiedzialny za zasilanie silników, drugi to stabilizator liniowy jednonapięciowy 78S05 odpowiedzialny za zasilanie procesora i reszty podzespołów. Oprogramowanie Program został napisany w języku C. Do podążania za linią używany jest regulator PD. Osiągnięcia - 6 miejsce Robomaticon Warszawa 2014 - kategoria Line Follower Standard (wtedy jeszcze pod starą nazwą) - 2 miejsce ROBO~motion Rzeszów 2014 - kategoria Line Follower Standard - 2 miejsce ROBO~motion Rzeszów 2014 - kategoria Line Follower Enhanced Zdjęcia i filmy Podsumowując jestem zadowolony z konstrukcji. Wiele się przy niej nauczyłem, wyeliminowałem błędy konstrukcyjne i programowe z pierwszego robota. Zachęcam do wyrażania opinii i uwag na temat robota jak i zadawania pytań.
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...