Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 4 punkty
    Z innych (dość nietypowych) oznaczeń wnioskuję, że płytka jest produkcji polskiej: US to układ scalony, "E" to elektrolit, MS to mostek prostowniczy a "TR" to zapewne triak. Idąc tym dropem DL to dlawik. Z resztą z układu widać, że strefa izolowana (za tym białym optotriakiem) ma obok głównego triaka specjalne, wysokonapięciowe kondensatory filtra przeciwzakłóceniowego. Tam dławik musiał się znaleźć obowiązkowo.
  2. 4 punkty
    Jestem zwolennikiem podejścia, w którym po zaobserwowaniu dużej liczby tematów na dany temat wyodrębnia się je do osobnej kategorii, aby utrzymać większy porządek. Tak stało się chociażby w przypadku Arduino. Pierwotnie tematy na temat tej platformy były w dziale Mikrokontrolery, a później powstała osobna kategoria tylko dla Arduino. Samo utworzenie kategorii na dany temat nie spowoduje raczej wysypu projektów i tematów dotyczących danego tematu. Przykładem są tutaj na przykład tematy związane z drukiem 3D. Przez ~2 lata na Forbocie były działy dotyczące drukarek 3D, skanerów, oprogramowanie itd. Panowały tam jednak pustki, ostatecznie całość została "zwinięta" do jednej kategorii "Druk 3D", która też nie jest zbyt popularna. Nie wiem czy jest sens tworzenia nowych kategorii tylko dlatego, aby były. Ktoś musiałby się takim działem zajmować, tworzyć poradniki związane z audio, opisywać własne projekty itd. Bez takiej osoby raczej będą tam pustki. Może lepiej na początku tworzyć takie tematy w dziale Elektronika i tagować je jako Audio? Dzięki temu będzie jasno widać jakie jest zainteresowanie taką tematyką
  3. 3 punkty
    To proste. Najpierw musisz wiedzieć jaki rezonator kwarcowy (bo chyba o tym elemencie myślisz pisząc "oscylator") masz lub potencjalnie możesz mieć. Oscylatorem/genratorem jest cały układ, czyli rezonator i wzmacniacz wbudowany w strukturę procesora. W tego typu generatorze (tzw. Pierce'a) kwarc pracuje w rezonansie równoległym (czyli elektrycznie pełni rolę cewki) a kondensatory obciążenia tworzą wraz z nim filtr przesuwający fazę w pętli sprzężenia wzmacniacza dokładnie o 180 stopni tylko dla częstotlwości rezonansu. Dlatego to działa Jeśli już znasz specyfikowany przez producenta C_load swojego kwarcu, to: Cx = 2 * (C_load - C_stray) gdzie: Cx to pojemność każdego z kondensatorów przy kwarcu, C_load no to oczywiście to co wyczytałeś z danych katalogowych rezonatora, C_stray to pojemności pasożytnicze nóżek/obudowy scalaka i ścieżek. Jeśli nie zrobiłeś wyjątkowo głupiej płytki z długimi ścieżkami to możesz tu przyjąć 2-4pF. Zatem dla typowego kwarcu wymagającego C_load = 15pF dostajesz Cx = 24pF więc typowo montujesz 22pF. Dla kwarcu 10pF możesz zamontować 2 x 15pF. I pamiętaj: od tych kondensatorów zależy także częstotlwość drgań rezonatora a więc i dokładność mierzonych przez procesor czasów czy generowanych przebiegów na wyjściach timerów.
  4. 3 punkty
    Nie ma czegoś takiego jak zasilacz halogenowy. Co to ma na wyjściu? Prąd stały czy zmienny? Podasz jakieś konkretne parametry? Być może zasilacz musi być obciążony jakimś minimum, i wtedy metr paska to za mało i albo drugi zasilacz, albo sztuczne obciążenie może byc potrzebne. Ale tych byćmożów to jest mnóstwo wielce za dużo
  5. 3 punkty
    Zobaczmy: 100mm/s to jest 6000mm/minutę, przy 1000 obrotach na minutę i przełożeniu 30:1 musiałbyś mieć koła o obwodzie 180mm, czyli o promieniu mniej więcej 2.86cm. Przy masie 200g (100g to same dwa ogniwa 18650 ważą) i takich kołach, potrzebujesz moment obrotowy 0.2*2.86=0.572kg*cm żeby podjechać na przykład pod próg albo inną przeszkodę. Te silniki dają ci 0.6kg*cm każdy, więc wydaje się, że masz zapas. Powinno działać. Update: Oczywiście zapomniałem o przekładni. Te 0.6kg*cm po przełożeniu będzie 30 razy więcej, więc spokojnie powinno dać radę, chyba, że moment podają już za przkładnią...
  6. 3 punkty
    Klonujesz repo BMP, budujesz dla stlink, wgrywasz bootloader USB blackmagic_dfu.bin przez UART (lub SWD), podłączasz USB, wgrywasz firmware blackmagic.bin, sprawdzasz czy arm-none-eabi-gdb widzi GDB na porcie szeregowym.Tu jest gotowa instrukcja: https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c Aha, firmware Black Magic Probe którego użyłem do niebieskich/czarnych płytek STM32F103 to build stlink. Więc oczywiście można go użyć do tych tanich gwizdków USB ST Link w metalowej obudowie, jeżeli komuś nie zależy na porcie szeregowym (PA9, PA10 nie są ładnie wyprowadzone na zewnątrz)
  7. 3 punkty
    Cześć, mam jedno pytanie: a nie boisz się, że zwierzakom w terrarium mogłoby się coś stać, gdyby w układzie wystąpił jakiś błąd (np. ustawienie zbyt wysokiej temperatury)? Szczerze mówiąc nie wiem, czy bym zaryzykował używanie własnego układu do obsługi terrarium, wolałbym chyba kupić profesjonalny termostat. Wiele lat temu miałem duże akwarium z ciekawymi okazami rybek (byłem wtedy w podstawówce) i wysiadł termostat sterujący grzałką. Gdy przyszedłem ze szkoły wszystkie rybki w tym akwarium były już ugotowane - uwierz mi to nie było przyjemne. Chodzi oto, że zbudowanie działającego niezawodnie urządzenia jest bardzo trudne (trudno przewidzieć wszystkie możliwe czynniki wpływające na pracę układu). Musiałbyś najpierw długo testować takie urządzenia, aby być pewnym, że w każdej sytuacji zadziała poprawnie. Komercyjne termostaty do terrarium mają takie testy za sobą (szczególnie gdy wyrób jest długo na rynku), więc ja wybrałbym sprawdzone urządzenie ze sklepu zoologicznego. Ale decyzja należy oczywiście do Ciebie. Pozdrawiam
  8. 3 punkty
    Generalnie to chyba rozpoczęcie transmisji się sygnalizuje stanem niskim na nóżce chip select — wtedy nie musisz szukać żadnych magicznych wartości.
  9. 3 punkty
    Jeszcze chce dodać, że napisał do mnie jeden kolega z Rosji, który jak okazało się, również produkuje w dokładnie taki sam sposób domowy filament na takiej samej maszynce. Przysłał do mnie zdjęcia przykładu swoich wyrobów z własnego filamentu. Pozwolił mnie na pokazanie tych swoich wyrobów z druku 3D. Bardzo mi się spodobało. Umieszczam te zdjęcia z pozwolenia ich właściciela. Teraz wymieniamy się zdobytym doświadczeniem. Powiedział mi, że już wypracował kilka kilogramów własnego filamentu, ponieważ tak jak i ja, zużywa sporo napojów i wody, tak że butelek nie brakuje. Swoją maszynkę zrobił sam na wzorzec z tego wideo: Na minucie 8:40 pokazuje jaki kawałek łańcucha z 4 ogniw wydrukował z takiego filamentu, wydrukowana od razu całość. Tak, że jeszcze raz udowadniam wszystkim przeciwnikom domowej produkcji filamentu z zużytych butelek, że jednak można robić własny filament i nadaje się on do druku 3D. A to, co piszecie, że nie warto w to się bawić, że to tylko marnowanie czasu, to już to sprawa każdego osobno. Jak człowiek ma chęć coś zrobić swoimi rękami i zobaczyć efekt swojej pracy, to jest jego sprawa osobista i nikt nie powinien mu tego zabraniać.
  10. 2 punkty
    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. 2 punkty
    To mój pierwszy post na tym forum ale od razu chciałbym przedstawić zbudowanego przeze mnie robota. Mimo że to pierwszy post to odwiedzałem to i inne fora wielokrotnie w poszukiwaniu przydatnych informacji i wykorzystując jedynie „magiczny” guzik szukaj udało mi się rozwiązać większość problemów z budową. To dla tych którzy nie chcą i nie lubią szukać… Wracając jednak do robota to został on nazwany X-walker i jest czteronożnym robotem kroczącym o symetrycznej konstrukcji. Został zaprojektowany jako robot którego zadaniem będzie przejście po nieznanym terenie przy jednoczesnym zachowaniu równowagi i odpowiednim położeniu korpusu. Prace nad robotem aktualnie się zakończyły, aczkolwiek temat jest obszerny i wiele można jeszcze ulepszyć albo dodać, więc w przyszłości robot zostanie poddany kolejnym modyfikacją. 1.Budowa mechaniczna Konstrukcja mechaniczna robota została zaprojektowana przy użyciu programu Autodesk Inventor 2010. Program ten umożliwił stworzenie wirtualnego modelu robota oraz przetestowanie zależności mechanicznych występujących pomiędzy jego elementami. Dzięki temu wybrano optymalne wymiary poszczególnych części. Poniżej na rysunku 1 zaprezentowano projekt robota z programu Inventor (bez elektroniki oraz okablowania): Na materiał konstrukcyjny wybrano aluminium jako, iż posiada odpowiednią wytrzymałość, jest przy tym lekkie i nadaje się do obróbki za pomocą prostych narzędzi. Zaprojektowane elementy wycięto przy pomocy lasera z 1.5mm i 2mm arkuszy aluminium. Poniżej przedstawiono wycięte elementy: Dalszy etap prac polegał na odpowiednim ukształtowaniu niektórych części. Proces ten odbywał się ręcznie przy udziale odpowiednich kopyt wykonanych z drewna bukowego i stali. Następnie dokonano montażu elementów przy pomocy różnego rodzaju łączników śrubowych o średnicach od 2 do 4mm. Dodano także inne elementy, takie jak tulejki dystansowe czy części składowe stóp ze zintegrowanymi czujnikami stykowymi. Na kolejnym rysunku przedstawiono złożonego robota: Poniżej przedstawiono szczegóły budowy stopy: Napęd robota stanowi 12 serwomechanizmów Power HD 1201 o parametrach przedstawionych poniżej (dane producenta): - moment 12.2/13.2 kg/cm - prędkość 0.16/0.14 sec/60° - napięcia 4.8/6.0 V - waga 60 g - wymiary 40.7 x 20.5 x 39.5 mm Niestety niektóre dane obiegają od wartości rzeczywistych, szczególnie wartość momentu, ale co ciekawe nawet wymiary nie są zgodne z rzeczywistymi. Podsumowując, konstrukcja mechaniczna robota posiada kilka charakterystycznych cech: - zwarta i solidna konstrukcja - podwójne łożyskowanie wszystkich stawów - zintegrowane czujniki stykowe w stopach - całkowita rozbieralność konstrukcji – tylko połączenia śrubowe - możliwie najmniejsze wymiary przy zastosowaniu danych elementów wyposażenia robota - liczne otwory odciążające konstrukcję 2. Elektronika Część elektroniczna robota posiada budowę modułową. Każdy moduł zawiera mikrokontroler AVR i pełni odpowiednie dla siebie funkcje. Każdy posiada także odpowiednio multipleksowane wyprowadzenie ISP, co pozwala programować moduły podczas ich działania. Moduły stanowią odrębne jednostki elektroniczne i można ich używać oddzielnie nie koniecznie w robocie X-walker. Do komunikacji między sobą wykorzystują SPI. Takie rozwiązanie nie ogranicza w dalszej rozbudowie robota i pozwala stale dodawać nowe elementy i funkcje. Poniżej scharakteryzowano poszczególne moduły. 2.1. Moduł sterujący „BRAIN” Jest głównym modułem w robocie, zawiaduje działaniem pozostałych. Został oparty na mikrokontrolerze ATmega 16A z kwarcem 16MHz. Posiada wyprowadzone piny z magistralą I2C i SPI, wyświetlacz LCD oraz 2 dodatkowe przyciski na potrzeby przyszłych funkcji. Poniżej krótka charakterystyka: - arbiter magistrali SPI - komunikacja z akcelerometrem i żyroskopem poprzez I2C - Realizacja filtru Kalmana w celu wyznaczenia aktualnego pochylenia robota - obsługa wyświetlacza LCD - nadzorowanie pracy innych modułów - formowanie odpowiednich ramek danych do komunikacji z PC 2.2. Moduły sterowników serw Robot posiada dwa takie same moduły sterowników serw, każdy obsługuje 6 serwomechanizmów, czyli 2 nogi robota. Moduły także oparte są o mikrokontroler ATmega 16A na kwarcu 16MHz. Najważniejszymi funkcjami tych modułów jest oczywiście generowanie odpowiedniego sygnału PWM dla serwomechanizmów, ale także obsługa czujników stykowych i pomiar napięć na potencjometrach serw (dodatkowy przewód wychodzący z każdego serwa). Ta ostatnia cecha służy sprawdzeniu czy serwomechanizm jest rzeczywiście wychylony od taką wartość jaką wyznacza sterowanie, co jest przydatne w pracy przy dużym obciążeniu. Należy dodać, że sygnały analogowe z potencjometrów przed dotarciem do tych modułów przechodzą przez filtr analogowy. 2.3 Moduł nadawczo odbiorczy „BT_RX_TX” Moduł ten jest odpowiedzialny za obsługę dwóch modułów bluetooth, jednego wysyłającego a drugiego obierającego dane z komputera. Dane przychodzące są odpowiednio filtrowane. W module zastosowano mikrokontroler ATmega 8A oraz kwarc 14.745MHz odpowiedni do transmisji szeregowej. Standardowo w module instaluje się dwa moduły bluetooth BTM-222. Poniżej zdjęcie przedstawiające moduł zamontowany w robocie: 2.4. Moduł zasilający "POWER" Robot jest zasilany dwoma zestawami akumulatorów. Pierwszy większy zestaw (2x LiPo 1850 mAh 7.4V) zasila serwomechanizmy, drugi mniejszy (LiPo 850 mAh 7.4V) zasila układy elektroniczne. Moduł zasilający monitoruje wartości napięć poszczególnych akumulatorów a także mierzy prąd jaki zużywają napędy robota. Zajmuje się także stabilizacją napięć – 5V dla elektroniki i poprzez stabilizator impulsowy (niewidoczny na zdjęciach) 5.3V lub 6V dla serwomechanizmów. Moduł zasilający posiada budowany układ dźwiękowy sygnalizujący niski stan napięcia w akumulatorach. Zajmuje się także monitorowaniem temperatury w istotnych miejscach robota za pomocą magistrali 1-wire oraz czujników DS18b20. Te miejsca to: stabilizator impulsowy dla serw, stabilizator liniowy dla elektroniki, temperatura w serwomechanizmie „udowym”, temperatura otoczenia. Zdjęcie użytego zasilacza impulsowego oraz zdjęcie robota po zamontowaniu modułu "POWER". Widoczny radiator stabilizatora liniowego elektroniki: 2.5 Pozostałe moduły Moduł żyroskopu Zawiera żyroskop cyfrowy L3G4200D oraz kilka elementów elektronicznych niezbędnych do jego działania . Na zdjęciu widać poprawiony błąd na PCB. Praktyczniej było to zrobić w ten sposób niż zmieniać całą płytkę bo wiązałoby się to z ponownym lutowaniem obudowy LGA żyroskopu. Moduł akcelerometru Zawiera akcelerometr (i magnetometr) cyfrowy LSM303DLH oraz tak jak moduł żyroskopu kilka elementów elektronicznych niezbędnych do jego działania. IMU - interial measurmet unit Moduł IMU czyli tzw. interial measurmet unit złożony i zamontowany w całości wraz z konwerterami napięć dla sygnałów magistrali I2C Moduł filtrów analogowych RC (2 sztuki) Filtruje napięcia na potencjometrach serw aby można było je prawidłowo zmierzyć poprzez wbudowane w mikrokontrolerach przetworniki ADC 3. Sterowanie X-walker jest sterowany za pomocą komputera PC i odpowiedniej aplikacji. Zastosowanie dwóch modułów Bluetooth pozwoliło na szybkie przekazywanie danych w obu kierunkach i uzyskanie kroku sterowania na poziomie 40ms. Czas ten nie jest niestety gwarantowany z racji zastosowania protokołu Bluetooth, aczkolwiek robot porusza się płynnie i reaguje błyskawicznie na zmiany sterowania. W jednym cyklu sterowania od robota odbierane są odpowiednie dane, wyliczane jest sterowanie i dane ponownie wysyłane są do robota. Na ekranie komputera możemy obserwować dane generowane przez wszystkie moduły robota jak również aktualne położenie środka ciężkości robota względem jego stóp z naniesionym wielokątem podparcia (obraz poniżej) Po wybraniu odpowiednich ustawień chodu robota oraz prędkości poruszania się następuję połączenie z robotem. O tej pory możemy nim sterować: chód przód, tył, na boki oraz obroty w lewo prawo. Wszystkie inne „akcje” związane z chodzeniem po trudnym terenie robot podejmuje sam. Na filmach poniżej można więc zaobserwować jak przekłada nogę w celu znalezienia odpowiedniego miejsca do położenia jej bądź też ratuje się przed wywrotką po obsunięciu się którejś z nóg. Innych elementów prawdopodobnie nie widać na filmach a mianowicie robot dba cały czas o odpowiednie usytuowanie środka ciężkości tym samym zapewniając sobie stabilność. Każdorazowo dobiera odpowiednie przemieszczenia nóg wzdłuż wszystkich osi oraz przemieszczenie korpusu. Korpus robota jest pozycjonowany automatycznie za sprawa sterowników PID które wyliczają sterowanie na podstawie danych z żyroskopu i akcelerometru przetworzonych przez filtr Kalmana. Wysokość korpusu nad ziemią także jest ustalana przez odpowiedni algorytm. Dodatkowo robot pilnuje aby każda noga która w danej fazie chodu ma spoczywać, w przypadku utraty podłoża „znalazła” nowe poprzez systematyczne obniżanie jej. Opis powyżej przedstawia pokrótce sposób w jaki sterowany jest robot, aczkolwiek nie zawiera wszystkich szczegółów. Zostały wymienione tylko główne funkcje algorytmów sterujących. Zdaje sobie sprawę że opis ten może być ciężki do zrozumienia, ale nigdy nie miałem talentu do opisywania tego co robie, więc śmiało można pytać i będę się starał rozwiewać wątpliwości oraz uzupełnić opis w miarę możliwości. Na koniec jeszcze kilka zdjęć i filmy: Kinematyka odwrotna: Kontrola przechyłu korpusu: Chodzenie po nierównym terenie: Chodzenie po ruchomej równoważni: I jeszcze coś w HD, łażenie po kamyczkach:
  12. 2 punkty
    Cześć, jednego kroku możesz nie zauważyć. Obuduj tą sekwencję zmiany stanów nieskończoną pętlą while lub for. Pozdrawiam
  13. 2 punkty
    Cześć, temat znalazłem dopiero teraz. Wiem że odkopuję ale myślę że warto, mało jest informacji o Black Magic Probe po polsku. Ja zrobiłem swoje BPM sam - wgrałem firmware na tą niebieską płytkę z STM32 F103 za 2$ - i używam w obecnym projekcie zamiast ST Link. Rzeczywiście BMPzawiera serwer GDB na pokładzie. Wystarczy podłączyć i otworzyć port szeregowy. Pierwsze wrażenie było takie że wgrywanie programu działa mi zauważalnie szybciej niż na ST Link, podejrzanie szybko musiałem dać dla pewności jakiegoś blinka czy tam hello world po serialu żeby mieć jakieś obserwowalne zmiany. Może to kwestia jakichś przesadnie zachowawczych domyślnych ustawień ST Link które można sobie zmienić, nie szukałem więcej. Debugowanie działa stabilnie, jeszcze mi się nie wywaliło ani razu. Do tego jest dodatkowy port szeregowy po tym samym kablu. Korzystałem tylko z programowania i debugowania STM32 po SWD, jest jeszcze JTAG i wspierane jest więcej rodzin MCU od kilku innych firm, choćby Nordic nRF51 i 52. Podsumowując jestem zadowolony. Mam oskryptowane flashowanie firmware BMP, jak komuś się przyda mogę udostępnić repozytorium.
  14. 2 punkty
    I kolejna ważna rzecz: silnik BLDC musi być zasilany w fazie z położeniem wirnika, tj. komutacje w zewnętrznym falowniku muszą następować w ściśle określonych momentach/położeniach wału. To zupełnie inaczej niż w typowym silniku AC, gdzie na stojan dajesz jakąś częstotliwość np. 20 czy 40Hz, wał kręci się zawsze trochę wolniej niż wirujące pole a moment powstaje właśnie dzięki poślizgowi jednego względem drugiego, bo tylko to generuje prąd w klatce wirnika. Jeśli bardziej obciążysz taki silnik to falownik nic nie musi o tym wiedzieć, wirnik zwalnia, moment wzrasta i wszyscy są zadowoleni. Przykład: zasilanie wprost z sieci AC 50-Hz. Tam przecież częstotliwość się nie zmienia i pole stojana zawsze wiruje tak samo szybko. W silnikach BLDC jest co do zasady bardziej jak w krokowych: wirnik musi kręcić się albo tak szybko jak pole albo wcale. Odwracając przyczynę i skutek: to falownik musi tak sterować polem by zawsze trochę wyprzedzać obecne położenie wału. Tylko tak powstanie quasi-stały moment obrotowy z którego chcesz skorzystać na wyjściu. Dlatego nie da się sensownie sterować silnika BLDC z głupiego falownika generującego na ślepo jakieś sygnały faz. Tak można zrobić tylko w przypadku małych obciążeń, małych (lub prawie zerowych) obrotów i sporego "przewatowania" sterowania czyli wtedy gdy masz pewność, że bez sprawdzania jego położenia wirnik robi to co mu każesz. Przykład: gimbale do kamer.Przy tak niskich obrotach (lub w zatrzymaniu) do sterowania w zamkniętej pętli musiałbyś mieć silnik oczujnikowany, bo back-EMF ze stojących uzwojeń nie wyciągniesz.
  15. 2 punkty
    Cześć, a jakie stany są na pinach sterownika: RESET i DIR oraz MS1,MS2,MS3? Przeczytałeś instrukcję do sterownika? Tą spod linku: https://botland.com.pl/pl/sterowniki-silnikow-krokowych/148-pololu-a4988-sterownik-silnika-krokowego-reprap-35v2a.html Pozdrawiam
  16. 2 punkty
    @nigraS Nie wiem do końca, co ma Kolega na myśli, ale wydaje mi się, że chodzi o "schowanie" zasilacza do taśmy LED? Jeżeli tak, dobrym rozwiązaniem jest wykorzystanie urządzenia, które sklepach internetowych znaleźć można pod hasłem "zasilacz taśmy LED do puszki". Wówczas takie coś "chowa" się do otworu w ścianie
  17. 2 punkty
    Jak się nie znasz to po co takie głupoty pisać ? Gdzie w tym kodzie widzisz sprawdzanie jakiegoś PWMa ? Ale z pisaniem własnego programu masz 100% racje ! Powiedziałbym, że przechowuje znak ale mniejsza o to. Co ma wspólnego znak w zmiennej ze znakiem-operatorem porównania ? Co ma to wspólnego z problemem kolegi. I dla czego ta odpowiedź ma w ogóle reakcje pozytywną ? Nie chcę, żeby to wyglądało na jakieś mądrzenie się, atak na was, czy coś, ale nie mogę po przeczytaniu takich odpowiedzi nie zostawić komentarza. Bo przecież człowiek przyszedł po pomoc, a wy wprowadzacie go w jeszcze większe niezrozumienie, albo piszecie odpowiedzi, które nie mają nic wspólnego z pytaniem. Trzeba by się trochę zastanowić zanim coś się napisze w internecie.
  18. 2 punkty
    coś mi się zdaje, że pokręciłeś i tam gdzie wyliczasz VAL podstawiłeś VOLT. dla 0° C spodziewałbym się wartości z ADC na poziomie 102 (przy 5v nap. referencyjnego), dla 50° C : 204 z ADC (dla 5V)
  19. 2 punkty
    Albo sprzedawać poza UNIE. Ja sprzedaje do Rosji, Białorusi, Ukrainy, Kazachstanu. Tam nie trzeba żadnych certyfikatów. A to CE również nić nie daje, to tylko znaczek. 90% to, co kupuje się w sklepach jest zrobiono w Chinach, a oni stawią znaczek CE tak po prostu. Kto to w Chinach ubiega się o certyfikację na CE??? Kompletny bezsens tak myśleć. Kupowałem tuby laserowe, zasilacze, wszędzie jest znaczek CE, tylko jak prosiłem o przesłanie kopii certyfikatu, to nić w odpowiedzi.
  20. 2 punkty
    Cześć, niedawno był wątek bardzo podobny i użytkownik forum chciał kupić jako swój pierwszy multimetr - multimetr wzorcowy Brynera za 2K PLN (taki jaki jest używany w mojej firmie do sprawdzania dokładności innych mierników). Watek według mnie trochę podobny. Ja osobiście używam Bitscope mini (BS10) i nie zamienił bym go na Hantek'a czy Rigol'a z 2 do 3 K PLN. Powody: 1) Jest dużo bardziej uniwersalnym narzędziem pomiarowym od taniego oscyloskopu stacjonarnego (takiego z 2K PLN) 2) Zajmuje dużo mniej miejsca 3) Software ma bardzo wymyślne funkcje i jest bardzo często aktualizowany 4) Wyświetlacz jest dużo większy 5) Jest tańszy Przedtem używałem przez 2 lata Bitscope micro: http://bitscope.com/product/BS05/ i byłem też zadowolony, ale od czasu gdy zacząłem zajmować si,ę układami FPGA to pasmo 20 MHz przestało mi wystarczać. W firmie dla której robiłem zlecenie przez kilka miesięcy używałem Hantek'a za właśnie gdzieś około 2 K PLN. Gdybym miał wybór wybrałbym Bistcope Mini ze względu na dużo większy zakres funkcjonalności i większy wyświetlacz. W pracy mam oscyloskop za około 20 K PLN i analizator widma za około 40 K PLN i razem mają zbliżoną do niego BS10 funkcjonalność (oprócz oczywiście od szerszego pasma częstotliwości). Oczywiście masz pełne prawo mieć odmienne zdanie i właśnie po to jest forum. Ja też kiedyś uważałem, że osobny oscyloskop jest lepszy, niestety praktyka tego nie potwierdziła. Stacjonarnego oscyloskopu nie wsadzisz do niedużego plecaka, czy torby, zajmuje sporo miejsca a często dostęp do zabudowanych urządzeń jest utrudniony (np. na jakichś wyjazdach serwisowych). Funkcje software'u są bardzo rozbudowane co często bardzo się przydaje i dość często aktualizowane. Nie obraź się, ale nie uważam, żeby zakup oscyloskopu analogowego miał większy sens niż cyfrowego Pozdrawiam
  21. 2 punkty
    Cześć, z opisu potrzeb, który przedstawiłeś najlepszy byłby dla Ciebie: http://bitscope.com/product/BS10/ Masz tu wszystko od oscyloskopu 2 kanały do 100 MHz (pasmo analogowe),8-mio kanałowy analizator stanów logicznych, poprzez generator sygnałowy, i analizator widma, a także analizator protokołów komunikacyjnych . Ma bardzo dobry rozbudowany software (wiele platform sprzętowych). No i obraz możesz powiększyć na cały monitor (jak masz monitor 32 cale to też). Ogólnie to pod względem możliwości dużo lepszy niż oscyloskopy, które wymieniłeś. Ma niestety jedną wielką wadę, która będzie go w twoich oczach dyskwalifikowała: jest za tani - kosztuje tylko 245 $ amerykańskich! Pozdrawiam
  22. 2 punkty
    Jaki jest sens zasilania termistora z 5V skoro masz 3.3V od procesora? Możesz oczywiście użyć dzielnika, ale to dodatkowe komponenty i niedokładności...
  23. 2 punkty
    Cześć, jeśli dobrze zrozumiałem jest to kod odbierający dane od układu FPGA (na mikrokontrolerze Nucleo-F746ZG). Czy mógłbyś zamieścić kod wysyłający dane z układu FPGA? Nie wiem jak masz to zorganizowane po stronie FPGA, czy jest to twój własny kod w języku HDL (VHDL lub Verilog), czy jakiś IP-Core, lub kod na soft/hard/CPU? Kod, który przedstawiłeś ma warunek: if (rx_spi5[0] == trig) Obawiam, się że ten warunek będzie spełniony bardzo rzadko (lub nigdy) i wtedy cała zawartość pętli while się nie wykona. Powinieneś użyć jakiegoś bufora FIFO do wysyłania i odbioru danych. Pozdrawiam
  24. 2 punkty
    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
  25. 2 punkty
    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.
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×