Tablica liderów

Ze względu na cenę, prostotę, wystarczającą do latania jakość i małe opóźnienia systemy FPV posługują się pradawnym standardem telewizji analogowej PAL. Dlatego na wyjściu takiego odbiornika dostajesz sygnał tzw. composite video po jednym drucie i to wprowadzasz do monitora, którym może być zwykły telewizor z odpowiednim wejściem, gogle itp. Jeśli chcesz taki sygnał wciagnąć do komputera (niechby i do Maliny) potrzebujesz tzw. frame grabbera czyli urządzenia, które "rozumie" analogowy sygnał CVSB, "rozpakowuje go" na kolejne ramki obrazu, ew. kompresuje i udostępnia w postaci cyfrowej np. przez USB. Poszukaj hasła "usb frame grabber" lub np. "usb video capture" - powinno pomóc. EDIT: Pierwszy z brzegu: https://rc-planeta.pl/pl/okablowanie-i-akcesoria/666-konwerter-fpv-usb-grabber-konwerter-video.html ale jest tego pełno.Szukaj w sklepach modelarskich albo RTV/AGD w działach video lub na aukcjach.

Witam chciał bym zaprezentować , drugą "lepszą wersję " kierownicy do komputera opartej na Arduino Leonardo. Film pokazujący jak dziala kierownica i Force Feedback: Jest to wersja elektronicznie taka sama jak poprzednia, wszystko opisane wcześniej link do poprzedniej tutaj : W tej wersji zmieniłem obudowę na znacznie mniejszą , lżejszą , łatwa do zamocowania przy stole, biurku itp. Obudowa została wykorzystana z kupionej przeze mnie za 50 zł kierownicy Logitech Formula Force Ex o obrocie 180* i Force Feedback. Dzięki temu że kierownica miała już przekładnie i ogólnie jest prosta w budowie , bardzo łatwo i tanio można ją przerobić tak aby miala kąt skrętu taki jak ustawimy sobie w programie np 720*,900* i Force Feedback do tego kąta obrotu. Tutaj link do gotowego software na Arduino Leonardo , od razu mówię że na Arduino Uno nie zadziała , link do pobrania w opisie filmu: Ja zrobiłem to tak: Na początku przez środek starej przekładni , dodałem pręt gwintowany o średnicy 10mm ,do którego z jednej strony mocowana jest kierownica, a z drugiej enkoder z drukarki canon ip2770. Aby zamocować enkoder musiałem wyciąć dziure jak widać na zdjęciu poniżej : Aby enkoder nie tarł o blat , dodałem plastikowe podkładki : A tak wygląda już gotowa sama kierownica: Wyjścia enkodera i do silnika , zostały przerobione na standardowych wyjściach które były w kierownicy i wchodzą do dodatkowej skrzynki w której znajduje się reszta elektroniki czyli w sumie tylko Arduino Leonardo i sterownik silników BTS7960: Jeszcze pedal box został przerobiony na taki aby miał 3 jednakowe pedały więc musiałem dokupić drugie takie same i wyciąć jeden i dokleić tak jak na zcjeciach . Schemat podłączenia wszystkiego w linku do wcześniejszej wersji. Efekt końcowy (pedały jeszcze stare): To by było na tyle , jeśli czegoś ktoś potrzebuje , śmiało pisać

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

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:

Świetny twór, aż miło się czytało i oglądało materiały, jak dla mnie opisu jak i nagrań mogłoby być więcej bo aż czuć niedosyt w obliczu tak świetnego robocika, których wszędzie jest pełno ale bez tak zaawansowanej automatyki ruchu, przynajmniej jeszcze nie widziałem. Odrazu życzę powodzenia w dalszym rozwoju projektu Zwrócę tutaj uwagę na filmik w którym robot przechodził przez klocki na równoważnie, miał przy tym duży problem i się szarpał żeby wyjść z opresji, a wystarczyło podnieść korpus wyżej, robot nie ma możliwości określenia jaki teren znajduje się wkoło. Jednak gdyby miał dodatkowe czujniki od spodu określające wysokość położenia korpusu nad ziemią to mógłby unikać takich sytuacji, jak i np przypadkowego uszkodzenia Jeszcze spytam czy robot potrafi chodzić szybciej ? Nawet jeśli tylko na płaskiej powierzchni, czy ma jakieś ograniczenie z tym związane, jeśli tak to czym jest spowodowane ?

W wolnej chwili zmodyfikowałem lekko poprzedni kod. Jest obsługa kropki i możliwość rozjaśniania i ściemniania wyświetlaczy LED. Zawęziłem również zakres niektórych zmiennych procesu. Ściemnianie i rozjaśnianie SW5 i SW6 na płytce ElbertV2. Kod w załączniku. Pozdrawiam. Licznik_LEDv1.zip

Nie wiem skąd wziąłeś to wymaganie na stosunek rezystorów będący potęgą liczby 10. Dlaczego miałoby tak być? Mostek to de facto dwa dzielniki tego samego napięcia. Całe zadanie polega na tym, by odpowiednio ustawić podziały. Możesz np. zacząć od stosunku 1:1 w gałęzi z termistorem (czyli tutaj 10k/10k) a w drugiej tak kombinować z rezystorami z szeregu E24 (masz 24 wartości więc 576 ich kombinacji z czego 24 są tym samym 1:1) by maksymalnie wyciąć składową stałą napięcia różnicowego. Dodatkowym ograniczeniem jest konieczność (wyjdzie później dlaczego) braku zmiany znaku tego napięcia w całym zakresie zmian temperatur pracy. To też musisz sobie jasno określić, bo przecież termistor będzie przede wszystkim w otoczeniu. Podczas wdechu będzie chłodzony powietrzem zasysanym do maski a podczas wydechu będzie ogrzewany ciepłem z płuc, ale to wcale nie znaczy, że w pierwszej fazie będzie spadał do 20 stopni (czy ile tam akurat jest) a w drugiej dociągał do 35 stopni. Zawsze będzie jakaś termiczna stała czasowa i to tym krótsza im mniejsza jest masa elementu i lepszy jego kontakt z powietrzem. Nawet przy powolnym oddychaniu masz kilka cykli na minutę a tylko połowa cyklu to jedna faza grzania/chłodzenia. To pewnie wyjdzie kilka sekund w najlepszym razie. Z kolei jadąc podjazd na wyścigiu oddycham pewnie z prędkością kadencji bo tak jest łatwiej, czyli 50-70 razy na minutę. Ludzie na łóżkach szpitalnych pewnie sie tak nie zdzierają, ale 10 oddechów na minutę to bym przyjął. A to oznacza 3s na fazę. W tym czasie termistor - nawet mały, na pewno nie dojedzie do temperatury otoczenia więc amplituda zmian będzie mniejsza niż wynikałaby z różnicy temperatur i na dodatek będzie malała wraz ze wzrostem szybkości oddechu. To tak jakbyś miał filtr dolnoprzepustowy i pracując na opadającej części jego ch-ki prznoszenia doprowadzał do niego coraz szybszy sygnał. Amplituda wyjściowa będzie spadać ze wzrostem częstotliwości. Dlatego napisałem zakres 19-24, bo waśnie tych kilku stopni (5-10) bym się spodziewał. No i teraz dochodzisz do pierwszego problemu: chcesz maksymalnie przybliżyć napięcie "stałej" gałęzi mostka do napięcia z gałęzi termistorowej będącej w spoczynku, bo to daje największe zmiany napięcia różnicowego (bo dobrze wycina offset). Z drugiej jednak strony musisz pamiętać o zmianach temperatury pracy całości. Inny sygnał dostaniesz gdy założysz komuś tę maskę w zimie na mrozie a inaczej gdy będzie ciepły, letni dzień. Dlatego może od razu warto pomyśleć o kompensacji temperaturowej? Gdybyś w drugiej gałęzi umieścił bliźniaczy termistor, ale schowany w układzie (lub umieszczony np. na zewnątrz maski, poza strumieniem wydychanego powietrza) to będzie on spełniał rolę termometru odniesienia. Napięcie w jego gałęzi będzie ustawiało się automatycznie do warunków, a to w drugiej będzie pływało z oddechem. Zrób modyfikacje schematu i tak policz oporniki dzielników by napięcie z jednej gałęzi było zawsze odrobinę większe (lub mniejsze, ale zawsze w tę samą stronę) niż w drugiej. W całym zakresie temperatur otoczenia i temperatur oddechu. Policz amplitudę wyjściowego napięcia różnicowego (a nie tego, które oddaje jedna gałąź dzielnika bo one osobno nas nie interesują) w temperaturze np. -10C i +25C przy założeniu, że zmiany temperatury termistora będą np. 12-stopniowe na mrozie i 5-stopniowe w temperaturze 25C. Bezpośrednie zasilanie baterią nie jest dobre, bo jej napięcie zmienia się w czasie pracy (rozładowanie) i od temperatury. A to zmienia napięcie wyjściowe mostka. Załóż roboczo, że napędzisz mostek ze stablizowanego Vcc (5V?) procesora.

VHDL zajmuję się od jakiś dwóch tygodni w wolnych chwilach. Na co dzień koduję w C/C++, LabView, na różne platformy sprzętowe. Czasem zachodzi jednak potrzeba użycia matrycy PLD np. dla procesów krytycznych w czasie - stąd moje zainteresowanie. Pozdrawiam.

Witam. Na podstawie ostatniej lekcji kursu, pozwoliłem sobie napisać kod w VHDL zliczający w górę i w dół ze zmienną prędkością oraz zerujący licznik. Efekty programu obrazowane są na 7 - segmentowych wyświetlaczach na płytce ElbertV2. Kod w załączniku. Switch0 - przyspiesza zliczanie Switch1 - Spowalnia zliczanie Switch2 - Reset zliczania Switch3 - Przytrzymanie - Zliczanie w dół. Pozdrawiam i czekam na uwagi, gdyż jestem początkujący w VHDL a temat jest wciągający ;-). Jak coś ciekawego jeszcze wytworzę to na pewno dam znać. Jakby ktoś miał inne przykłady np. wykorzystujące kartę microSD na płytce to jestem chętny. Pozdrawiam wszystkich. Paweł. Licznik_LEDv1.zip

W zasadzie tak. Pytanie, czy chcesz powielać przedszkolne rozwiązanie pokazane na stronce czy chcesz zrobić to (wciąż analogowo) ciekawiej. Zauważ, że cały ten tor cierpi na długie stałe czasowe a powodem tego jest nie tylko wolno zmienny sygnał wejściowy, ale i metoda jego obróbki - wzmacniacz odcięty od masy kondensatorem. Mamy zatem ogromną składową stałą (2V?) robioną w dzielniku a potem jest już tylko gorzej, bo słaby sygnał występujący na jej tle trzeba wzmocnić. Konieczne stało się odcięcie napięcia stałego, więc mamy 20-sekundowe stałe czasowe, układ doładowywania kondensatorów (niepokazany w całości więc niedziałający w tej formie), bo bez tego czas startu wynosi kilka minut no i powielenie tego samego filtra RC zarówno we wzmacniaczu jak w komparatorze. Ten z kolei bez histerezy czyli zrobiony jak mały Kazio wyobraził sobie porównywanie napięć. Chcesz zrobić to lepiej a już n a pewno ciekawiej np. bez elektrolitów 2200uF za to wciąż analogowo? Inną rzeczą jest to, że rozwiązań tego typu termicznego czujnika oddechu jest dużo: być może wystarczy jeden prosty wzmacniacz pomiarowy (a nawet i to nie) i reszta obróbki po stronie cyfrowej w procesorze.

Ok, czyli nie nasz pojęcia o działaniu części analogowej urządzenia jakie chcesz zbudować, napotkałeś fragmenty schematu których nie umiesz złożyć w całość i mimo wszystko nie zniechęcasz się. Zacznijmy zatem od podstaw: sprawdźmy czy rozumiesz jak to ma działać. Jeśli tak, to zapomnij o swoim schemacie i (ew. bazując na tym co napisano na stronie projektu) opowiedz własnymi słowami. Co jest sygnałem wejściowym, jak jest uzyskiwany, jak potem przetwarzany, jakie sygnały ma dostać procesor, po co i co będzie z nimi robił. Może powoli wyjaśni się co trzeba zrobić a następnie jak.Jeśli jakiegoś fragmentu nie rozumiesz lepiej napisz od razu choć mam nadzieję, że chociaż ogólne założenia pomysłu załapałeś. No to do roboty. Od razu uprzedzam, że gotowca ode mnie nie dostaniesz, a w celu uzyskania działającego schematu będziesz musiał się trochę wysilić.

Tak, układ jak na schemacie będzie działać - to katalogowe połączenie przekaźnika z wyjściem NPN. Wydajność prądowa zasilacza musi być większa niż zapotrzebowanie źródeł i tutaj jest to spełnione, a o ile większa to już w zasadzie nie ma znaczenia. Przecież akumulator samochodowy 12V o wydajności (chwilowej) 400A też by się nadał. Przykład z grochem jest jak najbardziej na miejscu, choć nie jestem pewien czy z kolei każdy podniesie ten worek... Zasilacz 12V/3A to już kawał sprzętu, wystarczyłaby jakiś taniocha, np. malutki, wtykany do gniazdka 12V/0.2A, no ale jeśli masz coś większego to podłączaj i powodzenia. Z punktu widzenia pieca musisz użyć zacisków 26/27 jak pokazuje instrukcja instalatora. Jeśli można między nie wstawić zestyk, to OK. Najlepiej, gdybyś pokazał tę stronę instrukcji.Wtedy nie byłoby wątpliwości.

Spokojnie - zasilacz może dać 3A ale nie musi - prąd jest zależny od obciążenia. To jest tak jakbyś potrafił podnieść 50 kilo cementu - ale przecież ziarnko groszku też podniesiesz. Zresztą czujnik potrafi podać 300 mA, a przekaźnik pobiera dziesięć razy mniej. Żadne rezystory nie są potrzebne, moim zdaniem powinno zadziałać (zaznaczam: moim zdaniem, nie mam takiego pieca więc autorytatywnie się nie chcę wypowiadać).

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.

W niniejszym artykule chciałbym opisać krótko jak za pomocą zestawu ElbertV2 uzyskać obraz na monitorze VGA. Moje rozwiązanie nie jest idealne, pojawiają się problemy z pierwszą linią i kolumną, o czym pisałem w wątku: https://www.forbot.pl/forum/topics51/przesuniety-obraz-na-monitorze-vga-vt14911.htm, więc jeśli ktoś ma pomysł na rozwinięcie, udoskonalenie, czy zwykłe poprawienie kodu, proszę śmiało pisać Warto przy okazji zwrócić uwagę, że ten projekt pokazuje zalety FPGA w porównaniu z mikrokontrolerami. Przykładowy sterownik zrealizujemy za pomocą niewielkiej części zasobów naszego i tak niewielkiego układu. Wygenerowanie obrazu za pomocą mikrokontrolera, o ile w ogóle możliwe zajmowałoby ogromną ilość jego zasobów. Projekt początkowo bazował na blogu, którego link podaje producent płytki (Numato): https://langster1980.blogspot.co.uk/2015/08/driving-vga-port-using-elbert-v2-and_7.html Zachęcam do porównania obu rozwiązań. Interfejs VGA Standard VGA używa sygnału analogowego do sterowania wyświetlaniem obrazu (w odróżnieniu od np. HDMI). Aby wyświetlić obraz musimy odpowiednio wysterować linie: • hsync - synchronizacja pozioma • vsync - synchronizacja pionowa • red, green, blue - kolor aktualnego piksela Podłączenie do zestawu ElbertV2 znajdziemy w jego dokumentacji: Rezystory na liniach kolorów realizują prosty przetwornik cyfrowo-analogowy. Obraz na monitorze VGA Tradycyjne monitory używały kineskopów, gdzie obraz był generowany na warstwie luminoforu za pomocą wiązki elektronow. W danej chwili wiązka elektronów była z ogniskowana w jednym punkcie ekranu tworzącym piksel. Elekromagnesy pozwalały na odchylenie tej wiązki i skierowanie w konkretny punkt na ekranie. Cykliczne "przemiatanie" obrazu sprawiało, że użytkownik widział stailny obraz. Obecnie monitory LCD właściwie wyparły tradycyjne CRT, jednak sposób sterowania pozostał niezmieniony. Obraz składa się z poziomych linii, każda linia z jednakowej liczby pikseli. Po wyświetleniu linii generowane są odpowiednie sygnały synchronizacji poziomej (hsync), a po narysowaniu ostatniej linii, sygnał synchronizacji pionowej (vsync). Aby uzyskać obraz na monitorze musimy więc wygenerować odpowiednie sygnały na liniach hsync, vsync oraz sam obraz za pomocą linii koloru. Dokładniejszy opis sterowania liniami znajdziemy na stronie: https://eewiki.net/pages/viewpage.action?pageId=15925278. Poniżej widzimy obrazek pobrany właśnie stamtąd: Sygnał synchronizacji ma ujemną polaryzację, czyli aktywny stan to logiczne "0". Jak widzimy podczas rysowania linii najpierw generowane są piksele obrazu, następnie mała przerwa (Front Porch), sygnał synchronizacji (Sync Pulse) oraz kolejna przerwa (Back Porch). Po niej rysowana jest kolejna linia. Synchronizacja pionowa przebiega podobnie, chociaż czasy są znacznie dłuższe. Rozdzielczość obrazu Obraz na ekranie może być generowany w różnych trybach - z różną częstotliwością odświerzania oraz rozdzielczością. Jako przykład wykorzystamy tryb o rozdzielczości 640 x 480 pikseli, z odświerzaniem 60Hz. Parametry dla tego trybu znajdziemy w tabeli na stronie podlinkowanej wyżej oraz w bardzo wielu miejscach w sieci. W każdym razie chcielibyśmy uzyskać następujące parametry: • Pixel clock: 25.175 MHz Synchronizacja pozioma: • Front Porch: 16 • Sync Pulse: 96 • Back Porch: 48 Synchronizacja pionowa: • Front Porch: 10 • Sync Pulse: 2 • Back Porch: 33 Pętla PLL W dokumentacji zestawu ElbertV2 znajdziemy informację o częstotliwości zegara taktującego, wynosi ona 12 MHz. Jak widzimy jest to za mało, ponieważ do wyświetlania potrzebny jest nam zegar o wyższej częstotliwości. Na szczęście Spartan3A, w który nasz zestaw jest wyposażony w moduły pętli PLL, dzięki której możemy zwiększyć częstotliwość pracy układu. Tworzymy nowe projekt, a następnie dodajemy nowy plik źródłowy (New Source). Jako typ projektu wybieramy "IP (CORE Generator & Architecture Wizard)". Następnie odnajdujemy komponent "Single DCM_SP". Przechodzimy przez kolejne opcja generatora. Następnie otworzy się nowe okno, tym razem z opcjami konfiguracji modułu. W pierwszym oknie wprowadzamy częstotliwość zegara, czyli 12MHz. Wybieramy również sygnał CLKFX: Opcje w kolejnych oknach możemy zostawić niezmienione, aż dojdziemy do ustawień generowanego zegara. Tutaj wprowadzamy docelową częstotliwość, czyli 25.175 MHz. Teraz możemy zakończyć konfigurację komponentu, powinniśmy zobaczyć nowy plik dodany do projektu. Jeśli będziemy chcieli, zawsze możemy zmienić konfigurację dwukrotnie klikając na tym pliku. Konfiguracja pinów Każdy projekt zawiera definicję używanych pinów. Do sterowania VGA musimy zdefinować podłączenia linii synchornizacji, kolorów oraz zegara dla samego układu Spartan. Plik ma postać: NET "clk" LOC = P129 | IOSTANDARD = LVCMOS33 | PERIOD = 12MHz; NET "hsync" LOC = P93 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "vsync" LOC = P92 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "blue[2]" LOC = P98 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "blue[1]" LOC = P96 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "green[2]" LOC = P102 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "green[1]" LOC = P101 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "green[0]" LOC = P99 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "red[2]" LOC = P105 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "red[1]" LOC = P104 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "red[0]" LOC = P103 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; Generowanie obrazu Zacznijmy niejako od końca, czyli od generowania danych obrazu. Moduł, który potrzebujemy będzie dostawał współrzęne piksela i zwracał jego kolor: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity display is port( clk : in std_logic; x : in integer range 0 to 1023; y : in integer range 0 to 1023; color : out std_logic_vector(7 downto 0)); end display; architecture Behavioral of display is begin process (clk) is begin if rising_edge(clk) then if (x < 640) and (y < 480) then if (x = 0) or (x = 639) or (y = 0) or (y = 479) then -- biala ramka color <= x"ff"; else if (y < 160) then -- czerwony pasek na gorze color <= x"e0"; elsif (y < 320) then -- zielony w srodku color <= x"1c"; else -- niebieski na dole color <= x"03"; end if; end if; else color <= x"00"; end if; end if; end process; end Behavioral; Aktualny kod to pierwszy i prosty test. W przyszłości należałoby go zastąpić czymś bardziej użytecznym, np. wyświetlaniem stanu gry (jeśli np. napiszemy grę w pong-a), albo użyć pamięci blokowej i wyświetlać zgromadzone w niej dane. Na razie na sztywno zapisany "obraz kontrolny" musi nam wystarczyć. Sygnały synchronizacji Kolejny krok to napisanie modułu generującego sygnały synchronizacji oraz zliczającego pozycję aktualnego piksela. Na ekranie rysowane są 640 piksele w linii, ale zliczanie współrzędnej x odbywa się od 0 do 799 - nadmiarowe wartości są używane do stwerowania sygnałem synchronizacji. Podobnie jest w przypadku synchronizacji pionowej: zmienna y obejmuje wartości od 0 do 525, ale tylko 480 linii jest widocznych. Warto zwrócić uwagę na "sztuczkę" ze zmiennymi next_x oraz next_y. Moduł odpowiedzialny za określanie kolorów pikseli musi ustawić dane niejako kolejnego piksela, podczas gdy wyświetlany jest poprzedni. Stąd użycie dwóch par zmiennych (z next_ i bez). library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity timings is port( clk : in std_logic; hsync : out std_logic; vsync : out std_logic; red : out std_logic_vector(2 downto 0); green : out std_logic_vector(2 downto 0); blue : out std_logic_vector(2 downto 1) ); end timings; architecture Behavioral of timings is signal x : integer range 0 to 1023; signal y : integer range 0 to 1023; signal next_x : integer range 0 to 1023; signal next_y : integer range 0 to 1023; signal rgb : std_logic_vector(7 downto 0); begin timings: process (clk) is begin if rising_edge(clk) then if (next_x = 799) then next_x <= 0; if (next_y = 525) then next_y <= 0; else next_y <= next_y + 1; end if; else next_x <= next_x + 1; end if; if (y >= 490) and (y < 492) then vsync <= '0'; else vsync <= '1'; end if; if (x >= 656) and (x < 752) then hsync <= '0'; else hsync <= '1'; end if; x <= next_x; y <= next_y; end if; end process; fb: entity display port map (clk => clk, x => next_x, y => next_y, color => rgb); red <= rgb(7 downto 5); green <= rgb(4 downto 2); blue <= rgb(1 downto 0); end Behavioral; Główny moduł Teraz gdy mamy już wszystkie elementy układanki przygotowane pozostaje połączyć je w moduł główny. Musimy w nim utorzyć instancje komponentu zegara (pll) oraz sterownika obrazu (timinig). Kod jest krótki i chyba nie wymaga komentarza: library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity vga_disp is port( clk : in std_logic; hsync : out std_logic; vsync : out std_logic; red : out std_logic_vector(2 downto 0); green : out std_logic_vector(2 downto 0); blue : out std_logic_vector(2 downto 1)); end vga_disp; architecture Behavioral of vga_disp is component pll is port ( CLKIN_IN : in std_logic; CLKFX_OUT : out std_logic); end component; signal clk_pll : std_logic; begin pixel_clock : pll port map (CLKIN_IN => clk, CLKFX_OUT => clk_pll); display : entity timings port map (clk => clk_pll, hsync => hsync, vsync => vsync, red => red, green => green, blue => blue); end Behavioral; Teraz pozostaje zsyntetyzować projekt, wgrać i cieszyć się obrazem na monitorze VGA. Dalsze plany Opisany projekt można dalej rozbudowywać. Użycie zasobów Elbert-a jest na poziomie 2%, więc jeszcze sporo można byłoby dodać, np. wbudowany mikrokontroler, obsługę UART-a, pamięć obrazu itd.

ja tak tylko wtrącę jeśli ktoś był by ciekawy jak wygląda main() w arduino int main(void) { init(); initVariant(); #ifdefine(USBCON) USBDevice.attach(); #endif setup(); for(;;) { loop(); if (serialEventRun) serialEventRun(); } return 0; } Źródło: arduino a technical reference (strona 170). Całość zaczyna się od strony 168 i można sobie to podejrzeć w bezpłatnej próbce na google play.

https://blynk.io/

No ale przecież o tym już pisałem - jedna pętla główna, żadnych while cośtam. Co to jest to "x2"? W głównej pętli nie powinno być nic po switchu (chyba że następny switch od drugiego automatu). Tak się właśnie programów nie pisze - jeśli po switchu nic by nie było nie miałbyś dylematu czy stosować wewnętrzna pętlę. Owszem - taki program będzie działać, ale nie życzę nikomu wprowadzania poprawek. Mówisz, że założeń nie można zmieniać... ano tak, Ty nie możesz, ale klient może i znając życie na 100% zmieni. Jak nie ten to następny co będzie chciał taki sam program ale trochę inny. A pomyśl, co by było, gdyby swego czasu chłopaki od Intela nie podrasowali nieco założeń klienta i nie wyprodukowali 4004...

@Mechano a to zwracam honor, rzeczywiście innowacja @Treker nie mam nic przeciwko powielaniu istniejących projektów — sam staram się tak projektować, żeby się moje konstrukcje dało łatwo powielić i cieszę się, kiedy ktoś to zrobi. Tylko jak sam zauważyłeś, napisanie nowej gry na arduboya wymaga więcej pracy i umiejętności, niż przeniesienie jego schematu na nowy rodzaj płytki drukowanej. Boli mnie, że to drugie jest świętowane jak pierwszy krok człowieka na księżycu, a to pierwsze przechodzi w zasadzie bez żadnego echa, ot po prostu jeszcze jedna gra. A czasem naprawdę są to osiągnięcia. Weź na przykład ten projekt: https://next-hack.com/index.php/2019/04/07/lets-build-an-handheld-platform-game-with-a-cortex-m0-microcontroller/

@atMegaTona skąd ten prześmiewczy ton? Przecież są gotowe rozwiązania poruszające się na gąsienicach i działają dobrze. Niżej przykład od iRobot:

Już kompletnie zdesperowany postanowiłem porównać pliki linkera generowane przez atollic i cubeide. Różnic jest ogólnie sporo ale zauważyłem na początku różnicę _estack = 0x2000A000; /* end of "RAM" Ram type memory */ i _estack = 0x20009FFF; /* end of "RAM" Ram type memory */ Zmieniłem to 9FFF na A000 (jak w Atollic) i poszło! Potem zacząłem zacząłem szukać pod tym kątem i jest takie coś: https://community.st.com/s/question/0D50X0000Ansc6GSQQ/stm32cubeide-linker-lptim-lsi-clock Troszkę inny kontroler, identyczne problemy, identyczne rozwiązanie. I piszą, że ST o tym wie ale się nie przejmuje. Czy to w takim razie może traktować jak poprawne rozwiązanie?

Tak właśnie zrobiłem tylko na win 10. Zainstalowałem arduino na czysty system jako pierwszą instalowaną aplikację ... A gdy nie zadziałało dodałem jave. A więc podsumowując: Nie udało się nic naprawić. Ostatecznie zrobiłem ponownie reset komputera zaznaczając opcję dokładnego czyszczenia dysku. Opierając się na tym co pisał Kaczakat na czystym systemie zainstalowałem arduino IDE se sklepu Windows i działa... Pobrałem też instalator ze strony arduino, zainstalowałem i też działa... Nie wiem co było przyczyną, ale widocznie coś padło w systemie. Jeszcze raz dziękuję wszystkim za zaangażowanie i pomoc.

załóżmy, że masz funkcję (nazwijmy ją pomiar) która wykonuje wszystkie potrzebne czynności i zwraca wynik pomiaru. long int wynik; int i; for (wynik=0, i=0; i < 100; i++) wynik += pomiar(); wynik /= 100; no i w zmiemnej wynik masz piękną średnią... może być?

I co naprawdę chcesz zrobić, bo być może da się uprościć samą metodę. Możesz opisać całość? ADC w ATmega168 możesz wystartować nie tylko na żądanie programu, ale także wyzwalać go ze źródeł sprzętowych. Konwersja może np. ruszać od timera 0 lub 1, sygnału z pinu INT0 a także z komparatora analogowego. Niestety nie można odpalić ADC w jakiś czas po takim zdarzeniu, więc te 300us musiałbyś odliczać innym timerem lub programowo, ale wiedząc to może jesteś w stanie zmienić koncepcję? Dlatego tak ważny jest opis całego układu i zasady jego pracy. Co oznacza "pomiar przez sekundę"?

Najlepszy jest enkoder jak w moim temacie co dałeś , z drukarki . Ma on 10000 impulsów. I ogólnie sprawuje się bardzo dobrze. Jeśli masz jakieś pytania odnośnie ffb czy coś pisz. Mam wszystko ogarnięte I też przerobiłem kierownice Logitech formuła force ex . I jest kozak dużo lepiej niż wcześniej na tej dużej obudowie , tam był problem z przekładnią a tu już były gotowe pod spodem filmik jak działa :