Tablica liderów

Ten artykuł jest tłumaczeniem (za zgodą autora) na język polski artykułu napisanego przez Paula Stoffregena, dostępnego pod adresem: https://www.pjrc.com/how-to-get-tech-help-from-strangers-on-the-internet/. Internetowe fora techniczne mogą być bardzo onieśmielające. Trzy proste zasady mogą znacznie ułatwić ci życie i zwiększyć szansę na uzyskanie pomocy, niezależnie od poziomu twoich umiejętności. Dobre Pierwsze Wrażenie — aby ludzie chcieli ci pomóc, Wyjaśnij Kontekst — aby ludzie zrozumieli czego potrzebujesz, Podaj Szczegóły — aby ludzie mogli ci pomóc, Poziom 1: Aby dostrzegli twój problem, Poziom 2: Aby mogli go powtórzyć. Dobre Pierwsze Wrażenie "Nie ma drugiej szansy na zrobienie pierwszego wrażenia" to ponadczasowe powiedzenie. Obcy ludzie błyskawicznie wyrabiają sobie o tobie opinię zaledwie na podstawie słów, obrazów lub nagrania w twoim komunikacie. Niech te słowa zadziałają! Największy wpływ na ludzką chęć do pomocy ma pokazanie, że sam włożyłeś wysiłek w rozwiązanie problemu. Ale jaki to może być wysiłek jeśli dopiero zaczynasz? Łatwo jest skorzystać z wyszukiwarki internetowej używając słów ze swojego pytania. Wielu ekspertów nie zdaje sobie jednak sprawy jak trudno jest znaleźć zrozumiałą i istotną informację gdy nie zna się właściwej terminologii, lub gdy te same słowa używane są także w niezwiązanych z twoim problemem dziedzinach. Zatem napisanie czego próbowałeś szukać i jakie wyniki są dla ciebie niezrozumiałe lub nie na temat może pomóc doświadczonym ekspertom w zrozumieniu twojej sytuacji. To nie wyniki są tutaj istotne, ale twój osobisty wysiłek. Szczera chęć nauki także zazwyczaj sprawia dobre wrażenie. Nawet parę słów pokaże twoje podejście. Bycie zniecierpliwionym, ale zdecydowanym na naukę na błędach robi dobre wrażenie. Inteligentni ludzie, którzy mogą pomóc, często doceniają szczere i uczciwe postawienie sprawy. Oczywiście jeśli już rozpocząłeś swój projekt i pracujesz nad nim, wspomnij o tym. Albo nawet lepiej, pokaż czego już próbowałeś. Zrzuty ekranu, zdjęcia, a nawet krótkie nagranie mogą doskonale zaprezentować co już zrobiłeś i upiec dwie pieczenie na jednym ogniu, jednocześnie komunikując i robiąc dobre wrażenie. Nawet kilka prostych słów dodanych do pytania, pokazujących że szczerze się starasz i chcesz się uczyć będzie mieć duży wpływ na odpowiedź, jaką otrzymasz. Kontekst Umożliwia Zrozumienie Istoty ludzkie mają niesamowitą umiejętność dogłębnego zrozumienia. Eksperci mogą zastosować swoją ogromną wiedzę do wypracowania twórczych pomysłów rozwiązujących twój problem... pod warunkiem, że będą wiedzieć czego tak naprawdę potrzebujesz. Kluczowe jest wyjaśnienie kontekstu pytania. Co chcesz osiągnąć? Jak twoje pytanie jest z tym związane? Jakie rozwiązanie byłoby dla ciebie idealne? Dlaczego? Kiedy zajmujemy się techniczną stroną zagadnienia, łatwo jest skupić się tylko na bezpośrednim problemie. Pamiętaj, że przyjaźni ludzie o ogromnej wiedzy i doświadczeniu regularnie czytają fora tylko dlatego, że lubią pomagać. Kiedy piszesz swoje pytanie, nie zapomnij opisać kontekstu. To może zmienić odpowiedź z technicznie poprawnej ale całkowicie bezużytecznej informacji, na rzeczywiście przydatną radę. Diabeł Tkwi w Szczegółach Współczesne zagadnienia techniczne często zawierają oszałamiającą ilość szczegółów. Ile informacji powinno zwierać twoje pytanie? Zanim je wyślesz, zastanów się nad tymi dwoma kwestiami: Czy czytelnik będzie mógł zrozumieć istotę twojego problemu? Czy będzie mógł go odtworzyć? Łatwo jest sobie zakpić "był jakiś błąd, ale zamknąłem go bez czytania", ale bądźmy poważni, minimalny poziom detali pozwoli czytelnikom zrozumieć problem. Zrzut ekranu lub dokładna kopia tekstu błędu, plus dokładna informacja o użytym oprogramowaniu, wersjach, sprzęcie oraz przedsięwziętych kroków to absolutna podstawa umożliwiająca czytelnikowi w ogóle dostrzec problem tak, jak ty go widzisz. W idealnej sytuacji ludzie czytający twoje pytanie powinni móc powtórzyć twój problem. Taki poziom szczegółowości nie zawsze jest praktyczny, ale jeśli dostarczysz wystarczająco dużo informacji, to szanse na rozwiązanie problemu znacznie się zwiększają. Pytania na temat programowania powinny zawsze zawierać cały kod źródłowy, a nie tylko wycięte fragmenty. Często problem ukrywa się w subtelnych szczegółach w definicjach zmiennych daleko od właściwego kodu. Doświadczeni programiści wiedzą czego szukać i potrafią dostrzec takie błędy natychmiast, jeśli tylko pokażesz cały swój kod. Nie zapomnij także poinformować jakich dokładnie bibliotek używasz. Zagadnienia dotyczące sprzętu elektronicznego często nie obejdą się bez zdjęć albo szczegółowych schematów połączeń, oraz linków do użytych części, lub ich symboli katalogowych. Nieśmiałość i niechęć do opisywania szczegółów swojego projektu na forum są powszechne. Nie wstydź się! Eksperci czytający forum naprawdę chcą pomóc. Pokaż dość szczegółów, wyjaśnij kontekst i pokaż, że się starasz, a oni z pewnością pomogą. Częste Błędy Fora nie zawsze działają idealnie. Powyższe trzy kroki najczęściej zadziałają, ale należy też pamiętać o kilku powtarzających się błędach: Zbyt Wiele Zgadywania Rozwiązywanie technicznych problemów polega na obserwacji i dedukowaniu przyczyn. Całkowicie normalne jest, że kiedy jesteśmy na tym skupieniu, to piszemy w zasadzie tylko na podejrzewanych przez nas przyczynach, a zapominamy opisać zaobserwowane efekty. Krótka przerwa przed napisaniem pytania często tutaj pomaga. Kiedy piszesz, staraj się myśleć z punktu widzenia czytelnika. Czy na pewno prosisz o pomoc w problemie, czy tylko chcesz, aby potwierdzili to co sam już odgadłeś? Z drugiej strony, opisanie jak doszedłeś do swoich wniosków może pomóc uniknąć niepotrzebnego powtarzania tego samego toku rozumowania. Nie ma idealnej metody. Po prostu pamiętaj, że zbytnie skupianie się na wnioskach może powstrzymać ludzi od pomocy. Dawanie Upustu Frustracji Szczerze mówiąc niektóre problemy są bardzo trudne i niesłychanie irytujące. Kiedy jesteś zły, dawanie upustu emocjom jest całkowicie naturalne. Zanim wyślesz wiadomość na forum, robiąc tak istotne pierwsze wrażenie, przeczytaj ją przynajmniej raz. Pewien poziom emocji jest normalny i może nawet pomocny. Pokazuje, że naprawdę się starasz. Ale strzeż się częstego błędu, gdy twoja wiadomość jest odbierana jako narzekanie a nie prośba o pomoc. Brak Odpowiedzi Nawet w idealnej sytuacji czasem nie dostaniesz odpowiedzi. To może rozczarować i przygnębić. Postaraj nie dać się ponieść tym emocjom i nie domagać się odpowiedzi. Jest lepszy sposób. Wysiłek jest istotny. Jeśli minęły całe dnie lub tygodnie od wysłania pierwszej wiadomości, to zapewne w tym czasie włożyłeś w swój projekt trochę więcej pracy? Nawet jeśli bezowocny, ten wysiłek jest czymś, czym warto się podzielić, aby przyciągnąć ludzi. Zdjęcia lub kod, albo inne efekty twojej pracy mogą bardzo pomóc. Czasem bardzo trudne i szczegółowe pytania pozostają bez odpowiedzi, bo po prostu nikt jej nie zna. Albo nikt nie jest pewien. W tej sytuacji dobrze jest zapytać o opinie albo sugestie w którym kierunku szukać odpowiedzi, aby usprawnić rozmowę. Ponownie, pokazanie wysiłku jest kluczowym czynnikiem zachęcającym ludzi do pomocy. Większość forów zniechęca lub nawet zabrania wysyłania wielokrotnie tej samej wiadomości czy "krospostowania". To prawie nigdy nie działa. Eksperci, którzy regularnie czytają fora — ludzie najbardziej skłonni do pomocy — na pewno to zauważą. Masz tylko jedną szansę na zrobienie dobrego wrażenia. Natomiast po dłuższym czasie bez odpowiedzi, ponowienie pytania, najlepiej z linkiem do poprzedniej wiadomości i dodatkowym wyjaśnieniem, nie musi być źle odebrane. Nierzetelni Uczniowie Na każdym forum zdarzają się leniwi uczniowie domagający się odrobienie za nich pracy domowej. Eksperci czytający fora regularnie są zalewani takimi marnymi pytaniami. Nie chcesz, aby twoje pytanie zostało potraktowane jak spam i zignorowane. Jeśli twój projekt jest robiony w ramach zajęć, to najlepiej jest szczerze się do tego przyznać (oraz do terminów) i upewnić się, że widać jednak twój własny wkład. Rzetelny wysiłek i szczera chęć nauki wyróżniają dobrych uczniów. Zastrzeżone Projekty Kiedy nie możesz podzielić się kodem źródłowym albo innymi szczegółami technicznymi, pomoc na forum rzadko będzie dobra. Zazwyczaj musisz poświęcić dodatkową pracę aby wydzielić problematyczny fragment z reszty projektu, aby móc go opublikować. Jeśli tego nie zrobisz i po prosty spytasz "czy ktoś spotkał się kiedyś z takim problemem", to traktujesz ludzi jak wyszukiwarkę internetową. Czasem może się udać, ale naprawdę trudno jest zgadywać na ślepo rozwiązania trudnych technicznych problemów. Jeśli twój pracodawca lub organizacja kategorycznie nie zgadza się na publikowanie kodu lub szczegółów, niezależnie jak drobnych, być może zamiast szukać darmowej pomocy na forum powinieneś użyć komercyjnych produktów, które zapewniają kontraktowo wsparcie, albo zatrudnić eksperta z firmy konsultingowej. Kiedy Otrzymasz Odpowiedź Najlepszym sposobem na wyrażenie wdzięczności jest wskazanie osoby, która udzieliła poprawnej odpowiedzi. Wielu ekspertów poświęca niezliczone darmowe godziny swojego czasu pomagając obcym na forach tylko dlatego, że lubią pomagać. Bycie docenionym jest miłą nagrodą. Kiedy twój problem jest rozwiązany, pamiętaj, że wielu innych ludzi trafi do tego wątku szukając rozwiązania podobnego problemu jeszcze wiele lat później. Najlepiej więc jest napisać na koniec krótką wiadomość podsumowującą poprawne rozwiązanie. Jeśli pytałeś w wielu miejscach, to wypada teraz odwiedzić każde z nich i podlinkować do wiadomości z odpowiedzią. O Tym Artykule (i Autorze) Przez ostatnie 6 lat odpowiedziałem 18620 razy na forum PJRC i nawet więcej na innych forach. Udało nam się w tym czasie stworzyć całkiem dobrą społeczność i pomóc w projektach wielu tysiącom ludzi. Obserwowałem i próbowałem się nauczyć co działa i jak możemy dokonać ulepszeń. Oczywiste stało się, że wielu ludzi potrzebuje nieco wsparcia w zadawaniu dobrych pytań. Najbardziej liczą się tu nie technikalia, ale subtelne czynniki ludzkie. Mam nadzieję, że wszystkie fora techniczne się poprawią. Proszę podzielcie się tym artykułem. — Paul Stoffregen

Jakiś czas temu w moje ręce trafił dość specyficzny zabytek techniki - układ MCY7880, będący jedynym mikroprocesorem produkowanym seryjnie w Polsce. Element ten był klonem intelowskiego procesora 8080, wytwarzanym przez nieistniejące już przedsiębiorstwo CEMI. Początkowo potraktowałem go jako kolejną elektroniczną ciekawostkę do kolekcji, po jakimś czasie zacząłem się jednak zastanawiać, czy nie będę w stanie wykorzystać go w bardziej konstruktywny sposób. Zacząłem więc gromadzić pozostałe elementy potrzebne do zbudowania prostego systemu mikroprocesorowego, jednocześnie wczytując się w dokumentację i literaturę komputerową z epoki. Właściwa konstrukcja zaczęła powstawać niewiele później. Z uwagi na mocno eksperymentalny charakter przedsięwzięcia zdecydowałem się pominąć etap projektowania PCB i od razu przystąpić do montażu komputera na płytce prototypowej. Najpierw wlutowane zostały podstawki pod układy scalone, potem grubszą srebrzanką poprowadziłem masę i linie zasilające. Należy tutaj nadmienić, że MCY7880 jest dość kłopotliwym procesorem, jeśli chodzi o zasilanie. Nie tylko pobór prądu jest duży jak na obecne standardy, ale także konieczne jest dotarczenie trzech różnych napięć: +12, +5 oraz -5V. Dodatkowo muszą być one podane w odpowiedniej kolejności, niedopełnienie tego obowiązku grozi uszkodzeniem procesora. Oryginalnie systemy mikroprocesorowe na MCY7880 były zasilane z dużych zasilaczy transformatorowych. Była to pierwsza z kilku kwestii, co do których zdecydowałem się na drobny kompromis i zastosowałem nieco uwspółcześnione podejście. I tak napięcie 12V jest generowane przez przetwornicę boost na MC34063A, a -5V jest pobierane z pompy ICL7660. Głowna linia zasilająca o napięciu 5V jest zasilana bezpośrednio ze współczesnego, stabilizowanego zasilacza impulsowego. Po poprowadzeniu masy i zasilania, a także wlutowaniu wszystkich elementów pasywnych, przyszedł czas na najbardziej mozolny etap projektu. Łączenie linii sygnałowych przy pomocy kynaru. Bardzo dużej ilości kynaru. Zajęło mi to kilka wieczorów. O dziwo pomyliłem się tylko raz, zapominając o podciągnięciu jednego z wyprowadzeń EPROM-u do 5V. Po przebadaniu magistrali oscyloskopem i analizatorem stanów logicznych stwierdziłem, że procesor zachowuje się prawidłowo pracując "na luzie" (szyna danych pociągnięta w sposób wymuszający ciągłe wykonywanie instrukcji NOP i zwiększanie licznika instrukcji). Przyszedł więc czas na zaprogramowanie pamięci EPROM. Na potrzeby tego projektu zaopatrzyłem się w chiński programator oraz urządzenie do kasowania tych zabytkowych pamięci. Zapoznałem się także z podstawami asemblera 8080. Pierwszy napisany program służył rzecz jasna do migania diodą podłączoną do znajdującego się na płytce układu 8255. Potem zabrałem się za portowanie TinyBASIC-a, który po jakimś czasie udało mi się odpalić na tym komputerze. Obecnie POLON 7880 może komunikować się ze światem jedynie przez port szeregowy RS232, zrealizowany za pomocą układu 8251 oraz konwertera MAX232. W planach na bliżej nieokreśloną przyszłość jest budowa dodatkowej płytki z interfejsem monitora CRT i klawiatury, a być może także i sterownikiem stacji dyskietek. Pozwoliłoby mi to na uruchomienie systemu operacyjnego CP/M - organizacja pamięci komputera jest do tego przystosowana. Oczywiście najprostszym rozwiązaniem byłoby symulowanie układów I/O za pomocą jakiegoś współczesnego mikrokontrolera, wolałbym jednak wykorzystać w tym celu oryginalne układy scalone z epoki.

Posiadając dwa futrzaki pojawiła się potrzeba zapewnienia im odpowiedniej ilości jedzenia, szczególnie podczas weekendowych wyjazdów. Przeglądając gotowe rozwiązania stwierdziłem, że najlepiej zbudować samemu mając przy tym sporo frajdy i satysfakcji. Urządzenie zostało zbudowane w oparciu o: Raspberry Pi Zero W Kamera do Raspberry Pi Serwo L360 Uchwyt na kamerę Czujnik odległości Główne cechy urządzenia Zdalna możliwość karmienia z dowolnego miejsca na świecie podgląd z ruchomej kamery ultradźwiękowy czujnik wykrywający kota oświetlenie IR pozwalające na podgląd w nocy możliwość wgrywania i odtwarzania dowolnych plików audio opcja "Text To Speach" duży 10 litrowy zbiornik na karę detekcja pustego zbiornika harmonogram automatycznego podawania karmy Pierwszym etapem i najtrudniejszym było wykonanie niezawodnego mechanizmu podającego karmę. Przetestowałem kilka rozwiązań: podajnik ślimakowy mechanizm koszykowy zasuwa podajnik tłokowy - to rozwiązanie sprawdziło się świetnie Układ podający powstał z ogólnodostępnych elementów PCV Niżej widok od tyłu pokazujący montaż tłoka Na filmie pokazana jest idea pracy mechanizmu, były to pierwsze próby ze słabszym serwomechanizmem. Ostatecznie został wymieniony na L360, a ruch obrotowy samego serwa zastąpiony ruchem "po łuku - przód, tył" co pozwoliło zapobiec ewentualnemu zakleszczeniu się karmy. Mechanizm - film Kolejnym etapem było wykonanie dodatkowej elektroniki obsługującej: 2 serwa do kamery 1 serwo podające karmę wzmacniacz audio czujnik odbiciowy IR czujnik zbliżeniowy Dodatkową wyzwaniem było przerobienie zwykłej kamery na kamerę NoIR, w tym celu zdemontowałem układ optyczny i delikatnie usunąłem filtr podczerwony. Poniżej wygląd matrycy po zdemontowaniu tych elementów. Po ponownym zamontowaniu soczewki, kamera działała już prawidłowo przy oświetleniu podczerwonym. Poniżej widok od spodu: Główne oprogramowanie sterujące sprzętem zostało napisane w pythonie, a interfejs użytkownika w PHP, na raspberry pi jest postawiony serwer www razem z mysql, tak więc jest to mały potworek do karmienia kotów. Sterowanie odbywa się przez stronę www, co wyeliminowało pisanie dedykowanej aplikacji na każdy z systemów osobno. Na koniec kilka dodatkowych zdjęć

Jakiś czas temu na forum pojawiło się kilka wpisów krytykujących Raspberry Pi jako platformę sprzętową. Nie próbuję nawet wmawiać, że malinka jest idealna - jednak niektóre problemy można rozwiązać bardzo (albo chociaż dość) łatwo. Problemy o których piszę to np. zużywanie kart SD, długi czas uruchamiania płytki, problemy z systemem plików jeśli nagle odłączymy zasilanie, długi czas kompilacji programów, czy brak możliwości uruchomienia systemu z pamięci USB. Wiele z opisanych niedogodności wynika ze sposobu używania malinki. Większość osób stara się zrobić z niej mały komputer PC - i nie ma w tym nic złego, w końcu na Forbocie właśnie tak opisywaliśmy kurs Raspberry Pi. Jednak malinka nie we wszystkim może zastąpić komputer stacjonarny i czasem nieco inne podejście może dawać nieco lepsze rezultaty. Komputer stacjonarny, a komputer wbudowany Pierwsza istotna sprawa to rozróżnienie między rozwiązaniami wbudowanymi (embedded), a komputerem stacjonarnym (desktop/laptop). Urządzenia wbudowane są konstruowane do spełniania jednej, z góry określonej funkcji - przykłady to procesor w ekspresie do kawy, bankomacie, czy samochodzie. Oprogramowanie można aktualizować, nawet zmieniać na własne (tym zajmują się hackerzy), ale nadal program ma ściśle określone zadanie do wykonania. System ogólnego przeznaczenia, to nasze komputery stacjonarne lub przenośne - czyli zupełne przeciwieństwo wbudowanych. Można na nich grać w pasjansa, Wiedźmina, a nawet inne gry, przeglądać internet, pisać programy i robić miliony innych rzeczy. Instalacja nowych programów jest łatwa, niekiedy nawet udaje się je odinstalować. Arduino jest kolejnym przykładem platformy wbudowanej. Program kompilujemy na PC, wgrywamy na płytkę i ma on wykonywać to co sobie zaplanowaliśmy - migać diodą, sterować robotem, itd. Ale już nowych progamów nie dodamy, nie będziemy na Arduino kompilować kodu, ani grać w pasjansa (chyba że to jest główna funkcja naszego układu). Raspberry Pi natomiast jest najczęściej używane jako mały komputer PC. Instalujemy na karcie SD Raspbiana (lub inną dystrybucję) i dalej używamy tak samo jak komputer stacjonarny. Może gier jest mniej, ale minecraft działa całkiem fajnie, RetroPie pozwala na emulację starych komputerów i konsol, a użwanie kompilatora (np. gcc) nikogo nie dziwi. Raspberry Pi całkiem dobrze sobie z takimi zadaniami radzi, ale to wbrew pozorom nadal głównie komputer wbudowany. W niniejszym artykule chciałbym chociaż wprowadzić w nową opcję, czyli użycie malinki jako komputera wbudowanego - mającego jedno zadanie, które dobrze wykonuje. System operacyjny Wszyscy wiemy jak działa Raspberry Pi - na karcie SD mamy ulubioną dystrybucję, kartę umieszczamy w czytniku, podłączanie zasilanie, czekamy, chwilę jeszcze czekamy, a może jeszcze jedną chwilę... i mamy pulpit z ikonkami albo chociaż konsolę do wydawania poleceń. Programy pobieramy z sieci (repozytorium), apt jest prosty i sympatyczny w użyciu. A gdybyśmy tak spróbowali przygotować własną, mniejszą ale dopasowaną do naszych potrzeb wersję systemu? Okazuje się że nie jest to aż tak trudne (chociaż proste też nie jest), w nagrodę będziemy za to mogli pozbyć się problemów o których wspominałem na początku artykułu. Yocto Własną dystrybucję Linux-a można przygotować zupełnie od podstaw - zaczynając od kompilacji kompilatora. Jest to jednak dość złożony proces, świetny do nauki, ale niekoniecznie wygodny. Na szczęście znajdziemy gotowe projekty przygotowujące naszą dystrybucję linuksa od podstaw. Buildroot (https://buildroot.org/) jest jednym z takich projektów - pozwala on na łatwe wybranie potrzebnych nam programów oraz ich skompilowanie ze źródeł. Ostatnio coraz większą popularność zyskuje jednak inny projekt - Yocto (https://www.yoctoproject.org/). Działa o wiele wolniej niż buildroot (jak to z narzędziamy opartymi o Pythona bywa), ale lepiej sprawdza się w dużych projektach. W następnym wpisie postaram się opisać jak można użyć Yocto to przygotowania własnej wersji systemu dla malinki. Jeszcze dwa słowa odnośnie buildroot-a. Dawno, dawno temu opisywałem jak użyć go podczas instalowania linuksa na netbook-u domyślnie pracującym z Androidem: https://forbot.pl/blog/sprawdz-jak-tanio-zbudowac-robota-z-systemem-linux-id7751 To co chcę teraz opisać to bardzo podobne rozwiązanie, ale zamiast netbook-a jest Raspberry Pi, a rolę Androida zajmuje Raspbian. No i po tych kilku latach yocto uzyskało pewną przewagę na buildrootem, więc też będzie użyte. Szybki start Żeby nie zanudzić najpierw szybki i dość ogólny opis. Celem będzie utworzenie podstawowego obrazu systemu, z którego wystartuje malinka. Najpierw należy przygotować odpowiedni komputer PC oraz system operacyjny. System to oczywiście Linux - wspierane są dystrybucje Debian, Ubuntu, Fedora, OpenSUSE oraz CentOS. Prawdopodobnie użycie innej dystrybucji jest też możliwe, może jednak wymagać dodatkowych kroków. W zależności od posiadanej wersji musimy zainstalować odpowiednie pakiety oprogramowania, wszystko znajdziemy opisane tutaj: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#required-packages-for-the-host-development-system Yocto można używać w systemie Windows lub MacOS wykorzystując maszynę wirtualną. Jednak takie rozwiązanie ma znaczącą wadę - bardzo spowalnia i tak czasochłonną kompilację obrazu systemu. Nie polecam takiego rozwiązania, lepiej używać natywnego linux-a i poszukać możliwie mocnego komputera - 4 rdzenie to raczej minimum, ale yocto potrafi nawet 44 wykorzystać (tyle testowałem), więc im silniejszy komputer tym lepiej i szybciej - a maszyny wirtualne pod względem wydajności niestety nie oszałamiają. Oprócz szybkiego procesora o możliwie wielu rdzeniach, będziemy potrzebowali również sporo miejsca na dysku. Minimum to ok. 30 GB, ale nieco bardziej rozbudowana konfiguracja może potrzebować i 100GB. Oczywiście szybki dysk ma swoje zalety, więc jeśli mamy miejsce na dysku SSD, warto go użyć. Ja wykorzystuję dysk SSD podłączany przez USB. To całkiem wydajne rozwiązanie, a możliwość odłączenia dysku od stacji roboczej i podłączenia do laptopa bardzo się przydaje. Dlatego u mnie ścieżka do projektu jest nieco długa: /mnt/usbssd/raspberry/yocto W tym katalogu należy pobrać sam projekt yocto, czyli wykonać: git clone -b sumo git://git.yoctoproject.org/poky.git Potrzebne będą jeszcze dwie tzw. warstwy, czyli powiedzmy biblioteki: meta-openembedded oraz meta-raspberrypi. Pobiera się je poleceniami: git clone -b sumo git://git.yoctoproject.org/meta-raspberrypi git clone -b sumo git://git.openembedded.org/meta-openembedded Teraz w katalogu /mnt/usbssd/raspberry/yocto znajdziemy trzy podkatalogi: poky, meta-raspberrypi, meta-openembedded. Pierwszy z nich jest dla nas najważniejszy więc wchodzimy do niego, a następnie wczytujemy zmienne ze skryptu oe-init-build-env: cd poky source oe-init-build-env Na ekranie widzimy podpowiedź co zrobić dalej, jednak zanim do tego przejdziemy musimy poprawić domyślną konfigurację yocto. Plik conf/bblayers.conf zawiera listę wybranych wartstw (bibliotek). Musimy dopisać używane przez nas, dopisujemy więc: BBLAYERS ?= " \ /mnt/usbssd/raspberry/yocto/poky/meta \ /mnt/usbssd/raspberry/yocto/poky/meta-poky \ /mnt/usbssd/raspberry/yocto/poky/meta-yocto-bsp \ /mnt/usbssd/raspberry/yocto/meta-raspberrypi \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-oe \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-multimedia \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-networking \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-python \ " Kolejny krok to edycja głównego pliku konfiguracyjnego o nazwie conf/local.conf. Domyślnie zawiera on dużo komentarzy, uproszczona wersja wygląda następująco: MACHINE = "raspberrypi3-64" DL_DIR = "${TOPDIR}/downloads" DISTRO ?= "poky" PACKAGE_CLASSES ?= "package_ipk" EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" CONF_VERSION = "1" RPI_USE_U_BOOT = "1" ENABLE_UART = "1" Pierwsza linia ustala typ naszej "maszyny", czyli Raspberry Pi 3 w wersji 64-bitowej. Jeśli używamy innej wersji, musimy odpowiednio zmodyfikować ten wpis. Co ciekawe cała dystrybucja będzie wykorzystywała ustawienia zoptymalizowane dla naszgo procesora - domyślnie Raspbian jest kompilowany tak, aby programy działały na najmniejszym wspólnym mianowniku, czyli starym Raspberry 1 - używając yocto nie tylko jądro, ale i cały system zostanie skompilowany pod nasze potrzeby. Nie zadziała na starszych płytkach, ale na naszej wykorzysta jej potencjał. Kolejny ważny parametr to ustawienie RPI_USE_U_BOOT. Dzięki niemu zostanie użyty bootloader u-boot, co pozwoli na załadowanie systemu przez sieć (TFTP), podłączenie dysku sieciowego (NFS), albo nawet użycie pamięci USB. Jest to pierwszy etap pozwalający na pozbycie się usterek na które wiele osób narzeka. W tym pliku można również wymusić użycie systemu "tylko do odczytu". Jedna dodatkowa linijka i karta SD będzie działać prawie w nieskończoność - do tego wrócimy później. Na razie czas zacząć kompilację i zrobić sobie (długą) przerwę. Wydajemy polecenie: bitbake core-image-minimal Yocto pobierze z sieci źródła wszystkich programów a następnie je skompiluje. Taki proces wymaga szybkiego łącza i trwa... od 20min do 4h. Na szczęście później jest już szybciej, ale za pierwszym razem można sobie zrobić przerwę na lunch. Po zjedzeniu lunchu, albo chociaż przerwie mamy gotowy obraz naszego systemu. Wynikowe pliki znajdziemy w katalogu tmp/deploy/images/raspberrypi3-64: Tym co na początek nas zainteresuje to plik z gotowym obrazem całej karty SD, czyli core-image-minimal-raspberrypi3-64.rpi-sdimg. Warto zwrócić uwagę na wielkość obrazu - u mnie wyszło 56 MB. To nadal bardzo dużo, ale domyślny Raspbian wymaga kilku GB. Kartę SD przygotujemy poleceniem dd, u mnie urządzenie /dev/sdh odpowiada karcie, więc polecenie: sudo dd if=tmp/deploy/images/raspberrypi3-64/core-image-minimal-raspberrypi3-64.rpi-sdimg of=/dev/sdh bs=4M Pozwala na nagranie obrazu na nośnik. Teraz można umieścić kartę w czytniku Raspberry Pi i wystartować system: Uruchomienie sytemu zajmuje znacznie mniej czasu niż w przypadku domyślnego systemu. To nadal bardzo daleka od optymalnej konfiguracja, ale i tak linux jest gotowy do pracy w kilka sekund. To co otrzymaliśmy to pierwsza, minimalna wersja systemu - mała ale zoptymalizowana dla naszego sprzętu. Nie znajdziemy na niej minecrafta, ani nawet interfejsu graficznego, ale to co wybraliśmy działa szybko i wydajnie. Mając taki system jako punkt wyjścia możemy przygotować bardziej rozbudowaną wersję, wyposażoną w potrzebne nam programy i biblioteki. Warto natomiast zwrócić uwagę na nieco inny sposób pracy z systemem. Całą kompilację wykonujemy na komputerze stacjonarnym, malinka tylko wykonuje przygotowane programy. Działa więc tak jak Arduino, a nie typowy Raspbian.

Zdecydowałem się przestawić swój kolejny projekt utrzymany w klimatach retro. Wszystko zaczęło się jakiś rok temu, gdy przypadkowo odkryłem, że sprzedawcy na popularnych chińskim serwisie aukcyjnym posiadają podejrzanie duże ilości podejrzanie tanich układów MOS6502. Wydało mi się to zbyt piękne, aby było prawdziwe. Z ciekawości zamówiłem kilka sztuk, płacąc za nie kilka dolarów i zapomniałem o całej sprawie, licząc na to, że pewnie otrzymam podróbki z wygrawerowanymi laserowo oznaczeniami. Jak bardzo się myliłem! Po uruchomieniu na płytce prototypowej okazały się być prawdziwymi układami MOS6502, wykonanymi w technice NMOS. Zabrałem się więc za projektowanie właściwej płytki, myśląc o stworzeniu swojego własnego komputera pracującego pod kontrolą języka BASIC. Ten projekt ciągle jest w realizacji, ale nie o nim chcę tutaj napisać. W międzyczasie bowiem w mojej głowie pojawił się jeszcze jeden pomysł. Chciałem sprawdzić jak ta rodzina procesorów sprawdza się w roli mikrokontrolera. Albo innymi słowy - byłem ciekaw co by było, gdyby Arduino powstało trzydzieści lat temu. Tym razem od brytyjskiego sprzedawcy na eBay-u zamówiłem kilka sztuk nowszych procesorów WDC65C02, wykonanych w technologii CMOS. Zastosowanie tej wersji układów nie tylko zmniejszało znacznie pobór prądu, ale także upraszczało układ, niwelując konieczność stosowania bufora szyny adresowej. Za punkt wyjścia do tego projektu posłużyła płyta procesorowa mojego ciągle powstającego komputera na MOS6502, która została poddana pewnym modyfikacjom. Przede wszystkim zmieniła się organizacja pamięci - zwiększyłem ilość EPROM-u kosztem RAM-u, dodana została także pamięć EEPROM. Organizacja pamięci wygląda następująco, zaczynając od 0x000: 8 kB pamięci RAM 8 kB przestrzeni adresowej I/O 8 kB pamięci EEPROM 8 kB układ EPROM (dodatkowa pamięć, obecnie niewykorzystywana) 32 kB EPROM (główna pamięć, przechowująca program, dane i adresy wektorów) Urządzenie pracuje z prędkością 4 MHz. Sygnał taktowania pochodzi z jednoukładowego generatora kwarcowego. Układ DS1232 odpowiada za obsługę wejścia RST (likwidacja drgań styków i obsługa power-on reset). Urządzenie posiada także port wyjściowy na 74HCT373 - można za jego pomocą migać dwiema diodami, pozostałe linie są wyprowadzone na złącze IDC-40. Dekoder adresów jest zrealizowany na układach 74HCT138 i 74HCT139. Dodatkowo kilka bramek układu 74HCT00 posłużyło do generowania sygnałów !RD i !WR, wykorzystywanych w układach kompatybilnych z magistralą intela (a więc także zastosowanych pamięciach). Wszystkie sygnały szyny danych, adresowej, te związane z obsługą przerwań oraz wyjścia dekodera adresów są wyprowadzone na złącze IDC-40. Moim zamiarem było stworzenie płytki, która nie tylko będzie mogła służyć do eksperymentów z historyczną rodziną procesorów, ale także będzie mogła posłużyć jako podstawa do budowy jakiegoś użytecznego projektu, poprzez dodanie odpowiednich modułów, na wzór shieldów Arduino - z tą różnicą, że podpinanych bezpośrednio do magistrali procesora za pomocą taśmy IDC-40. Na pierwszy ogień poszła płytka zawierająca wyświetlacz HD44780 (4x20) oraz kilka przycisków tact switch. Wyświetlacz pracuje bezpośrednio na magistrali procesora - do tego w końcu został zaprojektowany. Konieczne było tylko dodanie prostej logiki, generującej sygnały sterujące. Od strony programowej obsługa wyświetlacza w takich systemach jest nawet prostsza niż obecnie - wystarczy jedynie wpisywać odpowiednie wartości pod odpowiednie adresy w przestrzeni adresowej procesora. Przyciski posiadają własny port wejściowy, zrealizowany na 74HCT245. Praca nad tym projektem była dla mnie także okazją do zapoznania się z asemblerem 6502, chociaż prawdę mówiąc większość kodu napisałem w C posługując się kompilatorem cc65, uzupełniając go o asemblerowe wstawki. Co prawda jest to dość prosty kompilator i być może nie nadaje się do pisania gier pod Commodore C64, ale w w tego typu zastosowaniach sprawdza się całkiem nieźle.

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

Jak zbudować robota kroczącego? Na czym właściwie polega chodzenie? Jakie czujniki są do tego potrzebne? Na te pytania postaram się tutaj odpowiedzieć. Kroczenie a pełzanie Na początek zastanówmy się co tak naprawdę chcemy uzyskać. Aby zbudować urządzenie przemieszczające się bez kół nie potrzeba wiele — ot, dowolny mechaniczny aktuator wykonujący cykliczne ruchy może, na odpowiednim podłożu i przy odrobinie szczęścia, poruszać się jakimś mniej lub bardziej przewidywalnym kierunku. Istnieje nawet całkiem sporo publikacji naukowych o "robotach uczących się chodzić", w których te periodyczne ruchy są sterowane przez sieć neuronową lub inny ewoluujący element tak, aby zoptymalizować prędkość przemieszczania się. Ale ja osobiście nie nazwałbym tego chodzeniem, a już na pewno nie kroczeniem. Czego zatem wymagamy? Według mnie podstawowym i minimalnym wymaganiem jest to, aby żadna część robota nie była wleczona podczas przemieszczania się — aby tylko stopy dotykały podłogi i aby nie poruszały się względem tej podłogi przez cały czas gdy jej dotykają. Raz postawiona stopa musi pozostać w jednym miejscu aż nie zostanie ponownie podniesiona. W ten sposób gwarantujemy sobie dużą niezależność od rodzaju podłoża i minimalizujemy niszczenie jego oraz elementów go dotykających. Oczywiście w praktyce zawsze będą występować drobne ruchy: szpiczasta noga pająko-podobngo robota może, pozostając w miejscu, obracać się, a nawet stopa humanoida będzie się w momencie odbijania od ziemi lekko przesuwać. Ale wiemy już przynajmniej w którym kierunku chcemy... kroczyć. Kroczysz czy się toczysz? Drugim pytaniem, jakie musimy sobie zadać, jest jak dużo kontroli powinniśmy mieć nad ruchami nóg? Czy jeżeli z drewnianego koła od wozu drabiniastego zdejmę felgę i na odsłonięte tak drewniane szprychy pozakładam stare buty, to uzyskam urządzenie kroczące? Nasz pierwszy warunek jest w zasadzie spełniony — but raz postawiony na ziemi nie przesuwa się aż się od niej nie oderwie — jednak uzyskany sposób lokomocji niewiele różni się od zwykłego transportu kołowego, w szczególności dzieląc z nim problemy z radzeniem sobie z nierównym podłożem czy przeszkodami. To samo rozumowanie dotyczyć będzie wszelkiego rodzaju napędzanych jednym silnikiem mechanizmów takich jak Strandbeest czy Hexbugs. Jasne, wyglądają jakby miały nogi i chodziły, ale tak naprawdę są to tylko bardziej skomplikowane koła. W naszych robotach kroczących chcielibyśmy mieć kontrolę nad miejscem postawienia każdej nogi. Stopnie swobody Skoro jeden silnik to za mało, to w takim razie ile stopni swobody musi posiadać nasz robot żeby kroczyć? Powyższy warunek kontroli miejsca postawienia nogi daje nam minimalną granicę dwóch stopni swobody: poruszanie nogą i jej opuszczanie i podnoszenie. I rzeczywiście, można sobie wyobrazić robota składającego się z dwóch trójnogów przemieszczających się względem siebie w przód i w tył oraz w górę i w dół. W praktyce jednak najczęściej stosujemy konfiguracje wzorowane na zwierzętach, z osobnymi nogami o dwóch, trzech albo i więcej stopniach swobody. Niezależnie od konfiguracji, aby poruszać się w linii prostej nasz robot musi umieć podnieść i opuścić każdą z nóg, oraz przesunąć stojącą na ziemi nogę do tyłu wzdłuż linii prostej. Wymaga to dwóch stopni swobody, jeśli noga porusza się równolegle do ciała (jak u kota czy człowieka), lub trzech, jeśli noga porusza się po łuku (jak u pająka lub jaszczurki). Dodatkowo, niezbędne mogą być dodatkowe stopnie swobody jeśli noga posiada stopę, a także jeśli robot ma być w stanie wykonywać zakręty czy nawet obroty w miejscu. Należy się zatem przygotować na konieczność sterowania dużą liczbą aktuatorów (a także ich pozyskania i zasilania), co niestety często jest największą barierą przy budowanie takiego robota. Siła i masa Drugim, poza liczbą aktuatorów, wyzwaniem dla konstruktora robotów kroczących jest masa. Podobnie jak pojazdy latające, a w odróżnieniu od pojazdów kołowych i gąsienicowych, pojazd kroczący niesie własne ciało (plus ewentualny ładunek) siłą swoich silników. Istnieją co prawda bardzo wydajne chody pozwalające na odzyskiwanie i ponowne użycie znacznej porcji energii (ludzie właśnie taki chód stosują), ale są one na tyle zaawansowane, że nie mamy praktycznych systemów je wykorzystujących. Dla amatora-hobbysty pozostaje opcja niesienia całego robota energią baterii. Chcemy zatem, aby nasz robot był jak najlżejszy. Warto przy tym pamiętać o tak zwanym prawie sześcianów: przy zachowaniu wszystkiego innego, masa robota rośnie do sześcianu jego wielkości. Zatem jeśli robot wielkości 1m waży 10kg, to taki sam robot (tylko przeskalowany) o wielkości 2m ważyć będzie 80kg (możemy sobie wyobrazić 8 mniejszych robotów ustawionych w kostkę wewnątrz większego). Stwarza to wiele problemów, oczywiście, bo konstrukcja większego robota, przy użyciu tych samych materiałów, będzie tylko 4 razy mocniejsza, a silniki tylko dwa razy silniejsze. Na szczęście pojemność baterii także wzrośnie proporcjonalnie do sześcianu wielkości. Dlatego zdecydowanie łatwiej jest budować roboty o mniejszych wymiarach. Możemy sobie wówczas pozwolić na użycie tańszych i łatwiejszych w obróbce materiałów i słabszych silników. Oczywiście ograniczy to nam także wielkość i masę jednostki sterującej, ale przy postępującej miniaturyzacji jest to najmniej bolesne ograniczenie. Bardziej bolesne jest ograniczenie masy ładunku, którym nasz robot będzie w stanie manipulować — nie pojeździmy sobie na pająku. Jednak szczególnie dla początkujących zbudowanie małego robota będzie i łatwiejsze i bardziej praktyczne — łatwiej z nim eksperymentować i więcej się można nauczyć. Stabilność statyczna Dla uproszczenia zaczniemy od modelu, w którym nasz robot jest na tyle lekki i porusza się na tyle wolno, że siły bezwładności są pomijalnie małe i możemy je zignorować. W ten sposób z naszych obliczeń eliminujemy zmienną czasu i znacznie je upraszczamy. Dodatkowym ułatwieniem przy takim podejściu jest fakt, że nasz robot może się wtedy poruszać dowolnie wolno, a nawet w dowolnym momencie zatrzymać się bez przewracania. Oczywiście ogranicza to nas wtedy do statycznie stabilnych chodów, no ale od czegoś w końcu trzeba zacząć. W modelu bez inercji warunek stabilności robota jest bardzo prosty: obrysowujemy znajdujące się na ziemi stopy robota wypukłą obwiednią (czyli tak, jakbyśmy zrobili wokół nich pętlę ze sznurka i ją zacisnęli). Kształt, który uzyskamy nazywamy wielokątem podparcia. Jeśli stopy są szpiczaste, jak u insektów, to będą w narożnikach tego wielokąta. Jeśli mają inny kształt, to stanie się on częścią obrysu. Na przykład przy czworonożnym pająkopodobnym robocie i przy wszystkich nogach na ziemi, będziemy mieć czworokąt: A kiedy podniesiemy jedną nogę, uzyskamy trójkąt: Kiedy już mamy nasz wielokąt podparcia, to pozostaje nam znaleźć środek ciężkości naszego robota (uwaga — może się on zmieniać na skutek poruszania nóg czy innych elementów), poprowadzić z niego pionową kreskę aż do ziemi (zgodną z kierunkiem działania grawitacji) i sprawdzić, czy znajduje się ona wewnątrz naszego wielokąta. Jeśli tak, robot będzie stał. Jeśli nie, to znaczy że już się przewraca. Przy okazji, odległość tego punktu od najbliższego brzegu wielokąta podparcia jest dobrym wyznacznikiem stabilności robota — jego odporności na zewnętrzne siły. W przykładzie powyżej pionowy rzut środka ciężkości wypada dokładnie na brzegu trójkąta — zatem robot przewróci się od najdrobniejszego dotknięcia czy wibracji. Aby tego uniknąć, można przesunąć trzy nogi robota w kierunku tej, która ma zostać podniesiona zanim zaczniemy ją podnosić: To właśnie dlatego kroczące roboty często kiwają się na boki — przesuwają swój środek ciężkości, aby zawsze mieścił się w wielokącie podparcia. Stabilność dynamiczna Gdy chcemy, aby nasz robot poruszał się szybciej, a także potrafił chodzić z mniej niż trzema nogami na ziemi i bez rakiet śnieżnych, to musimy uwzględnić w naszych obliczeniach bezwładność. Jest wiele sposobów na zrobienie tego, ale niestety większość oznacza numeryczne rozwiązywanie skomplikowanych równań różniczkowych, co wymaga sporej mocy obliczeniowej. Istnieje jednak jedna dość prosta metoda nie wymagająca złożonych obliczeń, nazwana ZMP (zero-movement point). Czym jest ZMP? Pamiętacie ten punkt na ziemi bezpośrednio pod środkiem ciężkości robota? To właśnie jest ZMP w przypadku, kiedy inercja jest zerowa. W przypadku, gdy nie jest ona zerowa, punkt ten przesuwa się zgodnie z kierunkiem i siłą jej działania. Jest to po prostu punkt, w którym musielibyśmy się podeprzeć, żeby w danym momencie się nie przewrócić. Zatem wystarczy, że tak będziemy planować nasze ruchy, żeby ZMP nigdy nie znajdował się poza wielokątem podparcia na tyle długo, żeby robot się zdążył przewrócić, a wszystko będzie działać. No dobra, ale jak możemy wyznaczyć ZMP? Okazuje się, że jest na to kilka bardzo prostych sposobów. Jeśli mamy w stopach robota czujniki nacisku, to mierząc i uśredniając działające na nie siły jesteśmy w stanie wyznaczyć ZMP. Możemy też ZMP wyznaczyć przy pomocy akcelerometru, jeśli znamy środek ciężkość — wystarczy poprowadzić linię w kierunku wskazywanym przez niego, a tam gdzie przetnie podłogę będzie ZMP. Kinematyka odwrotna Aby mieć dobrą kontrolę nad tym co nasz robot robi i gdzie dokładnie stawia stopy, musimy opanować geometrię jego nóg i potrafić wyliczyć jak te nogi przesunąć żeby ustawiły się w danej pozycji. Takie obliczenia nazywane są kinematyką odwrotną i w przypadku nóg o dwóch lub trzech ortogonalnych stopniach swobody są relatywnie proste — wystarczy nam znajomość trygonometrii ze szkoły podstawowej. Cała sztuka sprowadza się do tego, aby współrzędne stopy móc przeliczyć na kąty w poszczególnych stawach nogi. Oczywiście dla każdej konfiguracji obliczenia będą inne, zatem nie będę się w nie tutaj bardzo zagłębiał. Oczywiście da się poradzić sobie z tym problemem bez obliczeń, po prostu zaszywając w programie poszczególne pozy naszego robota i przejścia między nimi. Niestety takie podejście nie pozwala nam modyfikować chodu w odpowiedzi na nierówny teren, dodatkowe siły, skręcanie czy zmianę pozycji ciała względem trasy — zatem daje naszemu robotowi niewiele przewagi nad zwykłym robotem na kołach. Układy współrzędnych Układ współrzędnych, w którym określana jest pozycja stopy względem ciała robota (a w zasadzie względem punktu przyczepienia nogi do tego ciała), to tylko początek. Oczywiście każda noga będzie miała swój. Ale jeśli chcemy naszego robota kontrolować jako całość (na przykład żeby przesuwać jego ciało celem odpowiedniego ustawiania środka ciężkości), to będziemy chcieli mieć drugi układ współrzędnych, wspólny dla wszystkich nóg — układ współrzędnych ciała. Następnie przydałoby się znać pozycję niejako środka robota, ignorującą przesunięcia ciała wynikające z balansowania i ruszania nogami — to, czym sterowalibyśmy przy pomocy zdalnego sterowania, na przykład. To układ współrzędnych wirtualnego pojazdu. No i wreszcie, jeśli nasz robot zapamiętuje mapę otoczenia, to wypadałoby mieć układ współrzędnych świata, w którym ten wirtualny pojazd się przesuwa. Przejścia pomiędzy tymi układami współrzędnych najłatwiej zrealizować poprzez mnożenie współrzędnych przez macierze przejścia pomiędzy bazami. W ten sposób trywialnie zaimplementujemy translację i rotację ciała robota. Chód Sam chód to prosta sprawa, choć oczywiście istnieje wiele wariacji na jego temat. Generalnie idea jest taka, że wszystkie nogi znajdujące się na ziemi przesuwają się do tyłu (najlepiej jednostajnie, choć można to też robić skokowo), a te najdalej wysunięte do tyłu są podnoszone i przestawiane do przodu kiedy tylko jest do tego okazja (na tyle szybko, żeby się nie skończył ich zakres ruchu do tyłu). W przypadku czworonogów istnieje optymalna kolejność takiego przestawiania (prawa-przednia, lewa-tylna, lewa-przednia, prawa-tylna) zapewniająca najlepszą stabilność, w przypadku dwunogów nie ma za bardzo wyboru, a sześcio-i-więcej-nogi mogą sobie pozwolić na dużo fantazji w tym zakresie. Statycznie stabilny chód u czworonogów jest jeden i nazywa się "creep" (skradanie się?) — polega na przestawianiu jednej nogi na raz. Gdy mamy stabilność dynamiczną, to możemy przejść do kłusu ("trot"), w którym przestawiamy dwie nogi na raz — po przekątnej, a nawet do galopu, w którym momentami tylko jedna noga dotyka ziemi (istnieją 4 wariacje tego chodu, w zależności od kolejności nóg). Jeśli mamy naprawdę szybki komputer i dobre czujniki (i silne aktuatory), to możemy nawet skakać... To tyle Tyle potrafię na ten temat napisać bez wchodzenia w szczegóły dotyczące konkretnych konfiguracji (humanoid, czworonóg, sześcionóg, etc.). Mam nadzieję, że jest to przynajmniej jakiś punkt startowy dla hobbystów projektujących swojego pierwszego robota kroczącego.

Budżet każdego cubesata zawierającego podobne komponenty jest podobny. Ceny podzespołów dla nas i w innych krajach są podobne, koszty rakiety również. Nie mam dokładnie takich informacji, ale np. w Stanach buduje się cubesaty na każdym uniwersytecie więc być może nie jest to takie wielkie wydarzenie jak u nas. Są normy np. europejskie ECSS, które są nieaplikowalne do cubesatów i innych satelitów (komercyjnych) z tzw. "new space". Nieaplikowalne ze względu na wymiary, budżet i szereg innych powodów. Warto jednak przeczytać i wybrać z tych standardów rzeczy aplikowalne. Cały satelita powstał z elementów tzw. COTS, czyli tego co można kupić w sklepie. Jednak nie były to przypadkowe elementy: co tylko było dostępne było wybierane w wersjach hi-rel (np. kondensatory, które mają określony failure rate), komponenty z serii z rozszerzonym zakresem temperaturowym. Nie były używane obudowy typu BGA czy DFN, szczególnie w "busie" satelity (czyli kluczowych elementach jak układ zasilania, komputer pokładowy itd.). Część kluczowych komponentów ma redundancję. Jak najbardziej. Może przy tak krótkiej misji nie ma dużej obawy o TID, ale single eventy i spowodowane nimi latch-upy mogą się zdarzyć. Po pierwsze staraliśmy się wybierać elementy które już leciały i się spisały (tzw. flight heritage), po drugie elementy COTS często bywają testowane ze względu na odporność na promieniowanie (CERN robi dużo takich testów i publikuje te dane, ale nie tylko oni). Mikrokontroler w komputerze pokładowym (OBC) ma zewnętrzne pamięci SRAM a ich zawartość przechodzi przez FPGA który robi korekcję błędów "w locie" tak, aby właśnie bity zmienione przez promieniowanie nie zakłóciły pracy. To samo z kodem programu - przechowywany jest w 6. kopiach a bootloader robi głosowanie na 3. slotach i dopiero wtedy ładuje poprawny obraz (potrafi go też naprawiać i sklejać). Samo oprogramowanie OBC w trakcie robi tzw. scrubbing na pamięciach. Z układu zasilania: wszystkie linie zasilania mają zabezpieczenia nadprądowe tzw. latch-up current limitter (LCL) - jeśli któryś podsystem dostanie latchu-upa od promieniowania to zostanie zresetowany. Tam gdzie to potrzebne i osiągalne. Redundancja szczególnie potrzebna jest w systemie zasilania (np. są dwa mikrokontrolery), system rozkładający anteny (mikrokontroler + rezystory przepalający linkę "trzymającą" anteny w pozycji złożonej) też są zdublowane. Sam żagiel ma dwa rezystory oddzielnie sterowane dla redundancji. Dochodzi też redundancja na poziomie systemu - nawet jeśli OBC przestanie działać - automatycznie otwarcia żagla dokona układ OBC (który ma dwa mikrokontrolery, a każdy z nich steruje oddzielnym rezystorem zwalniającym żagiel). Są ścianki z aluminium + zasobnik na żagiel i akumulatory to całkiem dobry shielding. Dobre pytanie - staraliśmy się wzorować na innych (na ich sprawdzonych rozwiązaniach), ale jest to dosyć ciężkie. Mało konstrukcji, nawet studenckich jest udostępnionych. Będziemy chcieli ze swojego projektu udostępnić jak najwięcej, w jak najlepszej formie. Przynajmniej ze strony elektroniki i software. Dużo wiedzy wynieśliśmy z Centrum Badań Kosmicznych, przeglądy projektu robiła ESA. Jeśli chodzi o materiały to są wspomniane ECSS i pewnie dziesiątki innych publikacji/materiałów z których korzystaliśmy a teraz "na szybko" ich tytułów nie wyczaruję. Wrócę na pewno do tego tematu za jakiś czas (pewnie po misji).

Nie samą maliną człowiek żyje Już na samym początku wspominałem o tym, że Raspberry Pi nie jest wcale ani jedyną, najlepszą, ani najtańszą platformą sprzętową dla wbudowanego Linux-a. Jej ogromnym plusem jest bardzo dobre wsparcie, ale nic nie stoi na przeszkodzie w używaniu innych płytek. I tutaj ważna uwaga - w bardzo podobny sposób możemy łatwo przygotować obraz systemu również dla innych platform. Yocto wykorzystuje tzw. warstwy - są to zestawy gotowych skryptów, jak dla mnie to takie moduły, czy biblioteki, ale ktoś wymyślił określenie warstwa więc będę się tego trzymać. W internecie znajdziemy całkiem sporo gotowych warstw, wiele osób przygotowuje własne - my też możemy, chociaż to chyba trochę bardziej zaawansowany temat. Co ważne warstwy pozwalają na oddzielenie części sprzętowej (BSP - Board Support Package) od reszty systemu. Więc zmieniając warstwę meta-raspberrypi na inną dostaniemy taki sam system (tzn. z takimi samymi pakietami), ale działający na innej platformie. Jakie platformy są wspierane? W sumie to prawie wszystkie - najlepiej do znajdowania warstw użyć wyszukiwarki: http://layers.openembedded.org/layerindex/branch/sumo/layers/ Wspomnę o kilku platformach, które moim zdaniem są warte uwagi: BeagleBone - jest domyślnie wspierana przez Yocto i włączona do dystrybucji Odroid (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-odroid/) - często wymieniane jako konkurencja malinki, na ogół wydajniejsze niż oryginał Xilinx (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-xilinx/) - tutaj znajdziemy wsparcie dla układów Zynq, czyli FPGA z Cortex-A9 Freescale (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-freescale/) - bardzo fajne procesory i płytki, trochę droższe ale z lepszą dokumentacją Intel (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-intel/) - yocto może też przygotować dystrybucję dla x86. Stary komputer może odzyskać drugą młodość jeśli potraktujemy go jako urządzenie wbudowane. Poza tym są wszystkie LattePanda i podobne (był też Edison, ale to już historia) Tegra (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-tegra/) - coś dla miłośników szybkich maszyn oraz GPU (albo hackerów Nintendo Switch) W nieco starszej wersji yocto mamy jeszcze większy wybór: Altera (http://layers.openembedded.org/layerindex/branch/rocko/layer/meta-altera/) - układy z FPGA oraz Cortex-A9, odpowiednik Zynq od Xilinx-a. Właśnie tej warstwy używałem przygotowując oprogramowanie dla mojego wyświetlacza paneli LED (https://forbot.pl/forum/topic/12015-wyswietlacz-z-paneli-led/) AllWinner (http://layers.openembedded.org/layerindex/branch/rocko/layer/meta-sunxi/) - to coś dla miłośników tańszych układów, znajdziemy je na wszelkiej maści OrangePi, BananaPi, NanoPi oraz Olinuxino Jeśli będzie zainteresowanie tematem Yocto, postaram się opisać nieco dokładniej możliwości jego wykorzystania z Raspberry Pi - ale większość omawianych możliwości można wykorzystać na innych platformach.

Metod samodzielnego wykonywania płytek pcb jest wiele. Termotransfer - potrzebna dobra drukarka laserowa, fototransfer - też dobra drukarka, płytki światłoczułe lub własnoręczne pokrywanie takim lakierem, suszenie, naświetlanie itp. Testowałem naświetlanie i albo prześwietliło albo odwrotnie. Można frezować. Ale można też rysować. Oczywiście nie ręcznie, jak to dawniej bywało. Jako, że z cnc i budową urządzeń mam trochę do czynienia, postanowiłem zbudować sobie taką małą maszynkę. Większość materiałów miałem - aluminiowe płytki, kątowniki, silniki krokowe i szlifowane prowadnice ze starych drukarek, a także dostęp do własnej małej tokarko - frezarki cnc. Całość miała być "po taniości" i maksymalne wykorzystanie "przydasiów" . Początkowo użyłem kilku gotowych podzespołów, jak stolik krzyżowy (proxxon) i mechanizm napędu ze starego CD/DVD jako oś Z. Użyte silniczki mają 24 kroki/obrót, zasilane z 12 V. Ich sterowniki to DRV8825 . Koła zębate pod paski też wyrób własny - frezowanie ( aluminium i poliamid ), paski trzeba było nabyć. Całością steruje Arduino Uno i GRLB1.1. Problem pojawił się w momencie zainstalowania krańcówek. Jedna oś działała, reszta martwa. CNC Shield był projektowany pod GRLB-8, a nowsze wersje tego oprogramowania mają pozmieniane niektóre wyprowadzenia. Ale jest to opisane na stronie GRLB. Nic nie pomagało - wgrywanie softu, czyszczenie procka i jego EEPROM'u. Oczywiście kontrola przewodów i samych krańcówek. Do "przyzwoitego" połączenia przewodów z układem sterującym przydają się złącza BLS. Dopiero nowa Atmega328 - i teraz wszystko gra. Nie spodziewałem się wadliwego układu. W ferworze walki o działające krańcówki została wykonana optoizolacja na układzie LTV847 . Płytkę do tego wyrysowała maszyna już sama dla siebie. Ponieważ wszystko działało, można by tak zostawić. Jednak pole robocze było małe - 45 x 120 mm. Trochę pracy trzeba było włożyć - cięcie, frezowanie i toczenie elementów. Ale warto było, bo powstałą dość solidna konstrukcja - już tak przyszłościowo.Dorobienie śruby i nakrętki (żeliwo) z kasowaniem luzu, mocowania silnika i łożyskowania śruby dopełnia reszty. Oczywiście dokładne ustawienie na czujnik zegarowy i dokładnym kątomierzem równoległości oraz kątów. W efekcie obszar roboczy zwiększył się do 180 x 120 mm. Większych płytek chyba robić nie będę. Mocowanie pisaka umożliwia ruch góra/dół - taki luz bezpieczeństwa - z uwagi na czasem spotykane niezbyt "płaskie" laminaty, natomiast luz poprzeczny jest minimalny i wg. pomiarów nie przekracza 0,03mm. Można więc mówić o precyzji . Oczywiście kusi przeróbka. W pierwszym rzędzie zmiana silników na taki krokowiec. Obecnie używane mają cienką oś - 2 mm, która wygina się od naciągniętych pasków. Ich łożyska cierne też się od tego mocno wyrabiają jednostronnie. Drugi powód - mocniejszy silnik umożliwi większą szybkość pracy. Obecnie to 300 mm/min. Nowa oś Z ( mocniejsza ) i zwiększenie jej zakresu pracy oraz obniżenie stołu roboczego. Zamiast obecnego mazaka - bo tylko tyle ten mały silniczek dźwignie - można by założyć jakiś moduł lasera albo i głowicę drukującą ( 3D ). Albo i mały silnik jako wiertarkę. W chwili obecnej pisak daje ścieżkę szerokości 0,4 mm lub wielokrotność. Próby z cieńszą ścieżką nie wypadły na razie pomyślnie - za słabe krycie i potrafią zostać przetrawione - używam chlorku żelaza.

Tym razem będzie nietechnicznie — to co tu opisuję, to wyłącznie moja własna prywatna opinia. Jeśli ktoś się nie zgadza, to zapraszam do dyskusji, jednak rezerwuję sobie prawo pozostania przy swoich wnioskach. Będzie o androidach, ale nie systemie operacyjnym dla telefonów, tylko o człekokształtnych robotach. Otóż uważam, że pomimo ich częstego pojawiania się w wiadomościach i na pierwszych stronach gazet, roboty tego typu są generalnie bezużyteczne poza bardzo wąską dziedziną zastosowań, jaką jest przemysł rozrywkowy. Jest tak z bardzo prostego powodu: humanoidalny kształt człowieka nie ma, z technicznego punktu widzenia, żadnych zalet, natomiast niesie ze sobą wiele nietrywialnych wyzwań. Zatem jeśli główną rolą naszego robota jest wyglądanie jak człowiek — po to, żeby stać na wystawie sklepowej i prezentować ubrania, iść w pochodzie, występować na scenie lub w filmie, bawić dzieci jako zabawka, czy zapewniać firmie dobrą prasę — to jak najbardziej ma sens nadanie mu właśnie takiego kształtu. W innych przypadkach nie ma to najmniejszego sensu, bo okazuje się, że wszelkie zalety takiego rozwiązania są tylko pozorne: 1. Zastępowanie ludzi w środowisku przystosowanym dla ludzi: używanie ludzkich maszyn i narzędzi, poruszanie się w mieszkaniach i biurach. Wydaje się, że to niezła racjonalizacja — jeśli dany robot ma zastąpić człowieka, to musi mieć możliwość sięgnięcia do wszystkich rzeczy, do których człowiek by sięgnął, wejścia w miejsce, w które człowiek może wejść i ogólnie robienia tego, co człowiek mógłby zrobić. Ale okazuje się, że można to osiągnąć bez kopiowania ludzkiego ciała. Co więcej, taki nie-człekokształtny robot będzie miał znaczącą przewagę, bo będzie mieć większą zwinność, lepszy zasięg, większą siłę i szybkość, nie mówiąc już o łatwiejszym sterowaniu. Roboty w rodzaju Robosimiania z łatwością mieszczą się wszędzie tam, gdzie człowiek, a są znacznie bardziej uniwersalne. 2. Interakcja z ludźmi. Wydawałoby się, że lepiej się będziemy czuć współpracując z czymś, co wygląda i zachowuje się tak jak my sami. Okazuje się, że wręcz przeciwnie. Im bardziej robot przypomina człowieka, tym bardziej obrzydliwy, wstrętny i straszny będzie się wydawał i tym gorzej przebiegać będzie interakcja. Zjawisko nosi nazwę "uncanny valley" i jest dość dobrze zbadane przez psychologów. Rozwiązaniem jest nadanie abstrakcyjnych lub komiksowych kształtów robotom, ale jeszcze łatwiej po prostu zaprojektować je tak, żeby ich kształt odpowiadał ich funkcji. 3. Wydajność energetyczna. Homo sapiens jest chyba najwydajniejszym biegaczem długodystansowym wśród zwierząt — potrafimy zagonić na śmierć konia. Nasz chód jest bardzo wydajny energetycznie — wybicie się z kostki pozwala na odzyskanie sporej części energii, która w innym przypadku zmarnowana by była na uderzeniu nogi w ziemię. Od dłuższego czasu próbujemy zbudować urządzenia, które by naśladowały ten chód. No ale przy całej tej wydajności tak naprawdę nic nie umywa się do transportu kołowego, który ma tą zaletę, że nie zużywa energii na ciągłą walkę z grawitacją. To między innymi dlatego wszystkie łaziki marsjańskie są na kołach, nawet jeśli mają pokonywać dość nierówny teren. Nawet jeśli kiedyś uda nam się zbudować dwunożne podwozie wzorowane na ludzkim chodzie, to przecież nie ma żadnego powodu dla którego jego górna część miałaby wyglądać jak człowiek. 4. Teleoperacja — w literaturze science fiction oraz filmach, szczególnie japońskich, często pojawia się pomysł robota sterowanego bezpośrednio ruchami człowieka. Pilot takiego robota, siedzący w jego wnętrzu lub w osobnym urządzeniu, jest zwieszony w specjalnej uprzęży (lub pływa w pojemniku ze specjalnym płynem) z sensorami, które każdy jego ruch przekładają na ruch robota. Robot jest przy tym często wielokrotnie większy i silniejszy od człowieka. Wydaje się oczywistym, że w takiej sytuacji najlepiej sprawdzać się będzie kształt kopiujący ludzkie ciało. W praktyce okazuje się jednak, że pomysł taki jest na dzień dzisiejszy praktycznie niemożliwy do zrealizowania w takiej postaci: utrzymywanie równowagi wymaga informacji zwrotnej, której nie mamy jak takiemu pilotowi przekazać. Być może kiedyś będziemy potrafili wpiąć się bezpośrednio w układ nerwowy pilota i w ten sposób sterować robotem, ale wówczas właściwie nie ma powodu, żeby nadal był on człekokształtny, a nie, na przykład, w kształcie goryla czy gibbona — przecież mamy nawet nerwy i odruchy potrzebne do sterowania ogonem! Na dzień dzisiejszy teleoperacja zazwyczaj ogranicza się do samych manipulatorów, czasem zamontowanych na ruchomej platformie — i to w zupełności wystarcza. Nawet nie mają na końcach ludzkich dłoni, tylko od razu narzędzia. 5. Seksboty. Bez komentarza — chyba tylko naprawdę zdesperowany nastolatek mógłby wpaść na taki pomysł. Podsumowując, w zasadzie nie ma żadnego powodu, aby budować praktyczne człekokształtne roboty. Jeśli ich wygląd nie jest celem samym w sobie, to warto zastanowić się nad projektem najlepiej przystosowanym do ich zadań, zamiast niepotrzebnie komplikować sobie życie próbując naśladować naturę.

Cześć, Myślę że każdy kojarzy monitory, które mają wbudowane oświetlenie z tyłu. Zawsze uważałem to za fajny dodatek, jednak producenci często słono sobie za takie monitory liczą. Dlatego postanowiłem, że stworzę własną wersję w oparciu o Arduino i taśmę LED RGB i chciałbym się z Wami podzielić efektami mojej pracy. Zacznę od spisu niezbędnych materiałów: Arduino Nano (ja użyłem klona) Taśma LED RGB 12V Zasilacz 12V, minimum 1A 3 tranzystory MOSFET IRL540N 3 tact switche Przełącznik bistabilny suwakowy 3 rezystory 10k Listwa goldpin żeńska Płytka prototypowa Przewody Niezbędna będzie też lutownica (i oczywiście cyna), przydatny jest także pistolet z klejem na ciepło oraz płytka stykowa i pojedyncza dioda RGB ze wspólną anodą (i 3 rezystory 330R) w celu sprawdzenia czy układ działa poprawnie zanim zaczniemy lutować. Jak już mamy skompletowany cały zestaw możemy zabierać się do pracy. Na początek schemat układu: Całość ma działać w taki sposób, że po naciśnięciu przycisku jasność danego koloru wzrasta, a jeżeli przestawimy pozycję przełącznika to tym samym przyciskiem będziemy przyciemniać wybrany kolor. Natężenie światła będzie regulowane przez sygnał PWM na portach Arduino, które będą podłączone do bramek tranzystorów unipolarnych. Warto zacząć od złożenia całości na płytce stykowej w celu skontrolowania czy układ działa poprawnie. U mnie wygląda to tak: Oczywiście żeby dioda zaświeciła potrzebny jest program dla Arduino: #define oswietlenieG 10 //PWM do bramki tranzystorów sterujących oświetleniem (przez R 10k) #define oswietlenieR 11 // -//- #define oswietlenieB 9 // -//- #define przyciskG 3 //przycisk zmieniajacy natezenie B #define przyciskB 4 //przycisk zmieniajacy natezenie G #define przyciskR 5 //przycisk zmieniajacy natezenie R #define przycisk 2 //przelacznik do zmiany znaku "zmiany" int R=0; //jasność koloru czerwonego int G=0; //jasność koloru zielonego int B=0; //jasność koloru niebieskiego int zmiana=5; //wartość o jaką zmieni się natężenie przy pojedynczym kliknięciu void setup() { pinMode(przycisk,INPUT_PULLUP); //definiowanie pinów pinMode(przyciskR,INPUT_PULLUP); pinMode(przyciskG,INPUT_PULLUP); pinMode(przyciskB,INPUT_PULLUP); pinMode(oswietlenieR,OUTPUT); pinMode(oswietlenieG,OUTPUT); pinMode(oswietlenieB,OUTPUT); } void loop() { if(digitalRead(przycisk)==LOW) //sprawdzenie czy przełącznik jest w pozycji "on" { if(digitalRead(przyciskR)==LOW) //sprawdzenie czy przycisk do zmiany koloru czerwonego jest wciśnięty { R=R-zmiana; //zmniejszenie wypełnienia if(R<=0) R=0; delay(20); //niwelacja drgań styków } if(digitalRead(przyciskG)==LOW) { G=G-zmiana; if(G<=0) G=0; delay(20); } if(digitalRead(przyciskB)==LOW) { B=B-zmiana; if(B<=0) B=0; delay(20); } } else { if(digitalRead(przyciskR)==LOW) { R=R+zmiana; if(R>=255) R=255; delay(20); } if(digitalRead(przyciskG)==LOW) { G=G+zmiana; if(G>=255) G=255; delay(20); } if(digitalRead(przyciskB)==LOW) { B=B+zmiana; if(B>=255) B=255; delay(20); } } analogWrite(oswietlenieR,R); //ustawienie zadanego wypełnienia na pinie R analogWrite(oswietlenieG,G); // -//- G analogWrite(oswietlenieB,B); // -//- B } Jeżeli wszystko jest połączone poprawnie dioda powinna zmieniać kolor gdy naciskamy przyciski. Jak już wiemy, że nasz układ działa, możemy przejść do lutowania go na płytce prototypowej. Zacząłem od przylutowania listwy goldpin do której będziemy wpinać nasze Arduino. Co prawda powinno się zaczynać od małych elementów, jednak w ten sposób łatwiej jest określić gdzie mają się znajdować tranzystory. Kolejno na płytce pojawiły się rezystory oraz mosfety. Na koniec przylutowałem wyprowadzenia zasilacza, przewody które będą biegły do modułu z przyciskami i piny z taśmy LED. Trzeba pamiętać o podłączeniu zasilania do wejścia taśmy. Do tworzenia połączeń bardzo dobrze się nadają odcięte końcówki wyprowadzeń rezystorów. Gotowa płytka wygląda u mnie tak: (tył jest lekko ubrudzony, bo pokryłem całość klejem na ciepło i nie udało mi się usunąć całego do zdjęcia) Następnie stworzyłem moduł sterowania. Połączyłem każdy przycisk, oraz wyprowadzenie przełącznika do wspólnej masy a do poszczególnych przycisków dolutowałem przewody z płytki. Całość zamknąłem w tekturowym opakowaniu, które zalałem klejem na ciepło: Co prawda nie wygląda to zbyt ładnie, jednak przykleiłem to na bocznej ściance głośnika, więc nie jest to widoczne. Teraz jest dobry moment żeby przeprowadzić test całości, jeszcze zanim pokryjemy całość klejem na ciepło (ja popełniłem ten błąd że nie zrobiłem testu i miałem przez to dodatkową robotę z usuwaniem kleju jak okazało się że jeden z tranzystorów nie działa). Jeżeli wszystko jest tak jak powinno możemy przejść do przycinania taśmy na właściwą długość a następnie polutowania odpowiednich wyprowadzeń (ponownie przydatne są ucięte "nóżki" od rezystorów) tak żeby stworzyć prostokąt który będzie pasował do naszego monitora. Gdy taśma jest już gotowa warto ponownie zrobić test i jeżeli wszystko działa poprawnie "zaizolować" łączenia za pomocą kleju na ciepło a następnie przykleić taśmę do monitora. Ja moją dodatkowo dokleiłem za pomocą taśmy izolacyjnej, żeby się lepiej trzymała: Teraz wystarczy podłączyć taśmę do naszej płytki, wpiąć Arduino i całość powinna nam pięknie świecić: Mam nadzieję, że mój projekt się Wam spodoba i sami spróbujecie stworzyć takie oświetlenie, bo efekt jest naprawdę warty poświęcenia czasu. PS. Zamiast przycisków można by użyć np. modułu bluetooth albo odbiornika podczerwieni i dowolnego pilota od telewizora, ale ze względu na to, że sterowanie w moim przypadku znajduje się w łatwo dostępnym miejscu uznałem że byłaby to niepotrzebna komplikacja. Pozdrawiam ~Usohaki

Wstęp O projekcie myślałem od czerwca poprzedniego roku, to jest 2018. Postępy prac opisywałem tu - cel projektu stanowiła budowa robota klasy SCARA - dwuosiowego ramienia robotycznego manipulującego efektorem w płaszczyźnie XY, z funkcją grawerowania laserowego oraz mini- wrzecionem modelarskim, rysowania mazakiem i pick&place realizowanym techniką próżniową. SCARA to akronim słów Selective Compliance Articulated Robot Arm, co oznacza, że robot w osiach X i Y porusza się obrotowo względem siebie i liniowo w osi Z. Dzięki temu, SCARA jest szybsza (w porównaniu do maszyny pracującej w układzie kartezjańskim), pozwala na osiągnięcie zadanego w obszarze roboczym punktu dwoma trajektoriami, a także umożliwia łatwy montaż połączony z niewielkimi rozmiarami w porównaniu do pola roboczego, który oferuje (klasyczna konfiguracja XYZ cechuje się faktem, że pole robocze musi być mniejsze od rozmiarów samej konstrukcji). Nie może natomiast przenosić dużych sił, a samo sterowanie wymaga zastosowania równań trygonometrycznych oraz interpolowania w momencie, kiedy końcówka ma wykonać ruch po linii prostej. Ponadto, roboty tej klasy cechują się mniejszą sztywnością. Całość sprawia, że ramiona robotyczne tego typu są idealne dla lekkich aplikacji, gdzie często wymagana jest szybkość, higieniczność (małe natężenie hałasu) oraz łatwość instalacji połączona z niewielką ilością miejsca, czyli w zastosowaniach "podnieś i przenieś" lub operacjach montażowych, chociaż z powodzeniem może posiadać koncówkę roboczą typową dla tradycyjnych maszyn CNC. Mechanika i elektronika Prostokątna podstawa robota o wymiarach 320x240mm została numerycznie wyfrezowana, z plexi o grubości 16mm. Otwory, służące zamocowaniu silnika oraz dysku łożyskującego I stopień swobody zostały nagwintowane gwintem M5. Wszystkie elementy 2D, które osobiście frezowałem, projektowałem w Solid Edge 2019. Najwięcej problemów miałem z przekładniami (zwiększenie momentów obrotowych silników oraz rozdzielczości (stosunek ilość kroków/obrót) oraz konieczność przenoszenia dużych sił, zgodnie z równaniem dźwigni jednostronnej) - właściwe ramię jest przymocowane do koła zębatego, które łożyskowane jest przez dysk z poliamidu (przeniesienie sił osiowych) oraz wciskane łożyska 6008RS (przeniesienie sił promieniowych). Oś koła stanowi imbusowa śruba M10, przykręcona nakrętką samohamowną z podkładką. W obydwóch stopniach swobody, przekładnie pasowe działają w oparciu o zamknięte paski zębate o module HTD 3mm, które pochodzą ze znanych robotów kuchennych "KASIA". Koła zębate, podobnie jak inne wydruki 3D, wykonano przy pomocy drukarki Zortrax M200. Wykorzystałem bardzo dobry filament ABS firmy Spectrum. Drugi stopień swobody działa i założyskowany jest identycznie z tą różnicą, iż wykorzystano jedno łożysko kulkowe, a dysk wykonano z ABS-u. Warto zaznaczyć, że każdy z uchwytów silników krokowych posiada podłużne otwory, tak zwane "fasolki", które pozwalają na regulację naprężenia paska. Średnice osi silników krokowych to odpowiednio 6,35mm oraz 5mm, niezawodne połączenie małych zębatek z gładkim wałem uzyskano poprzez wcisk na gorąco oraz ścisk dwoma śrubkami imbusowymi M3. Drugie z ramion można łatwo zmienić, w zależności od tego, jaką funkcję ma pełnić robot (na zdjęciu koncówka z modułem lasera IR 500mW). Każde z ramion ma długość 200mm, zatem maksymalny obszar roboczy konstrukcji (bez uwzględnienia faktu ograniczenia go przez wieże silników i podstawę) to koło o średnicy 800mm. Wymiana ramienia (a co za tym idzie - funkcji) jest łatwa i przyjemna, zajmuje mniej niż 5 minut. W robocie nie zastosowano czujników krańcowych, pozycję zerową ustawiam ręcznie w linii prostej. W precyzyjnym ustawieniu pozycji zerowej pomocne są specjalne znaczniki (zdjęcie poniżej), zakładane tylko na czas zerowania. Drugie zdjęcie przedstawia budowę, a trzecie - mosiężne emblematy, jakimi ozdobiłem podstawę Wykorzystałem silniki krokowe, NEMA23 i NEMA17 Osobny blok funkcjonalny robota stanowi sterownik, którego zdjęcie przedstawiono poniżej - połączenia z urządzeniami zewnętrznymi (silniki krokowe oraz efektor) zrealizowane zostały złączami JST-BEC (bądź 3-pinowym złączem 0,1" jeżeli efektorem jest serwomechanizm modelarski). Do zasilacza sterownika (1) podłączany jest przewód zasilający sieciowy. Napięcie wyjściowe wynosi 12V DC, a wydajność prądowa zasilacza to 5A. Celem sterowania robotem (kiedy nie jest wgrana zaprogramowana sekwencja ruchów) należy podłączyć przewodem USB typu B do komputera PC płytkę Arduino UNO (6), która stanowi "mózg" sterownika - podaje ona sygnały sterujące pracą silników krokowych (HY-DIV268N oraz TB6560 - odpowiednio 2 i 3), serwomechanizmu i/lub przekaźnika (7), który może załączać palnik laserowy lub elektrozawór. Płytka (5) posiada bezpiecznik, diodę - wskaźnik napięcia (na płycie znajduje się również woltomierz (9)), kondensatory chroniące przed chwilowym spadkiem napięcia zasilania oraz umożliwia podłączenie każdego modułu odpowiednio pod linię 12V DC lub 5V DC (dla logiki), za którą odpowiedzialny jest moduł stabilizatora szeregowego (8) - LM7805. Zadaniem wentylatora (4) jest chłodzenie sterowników silników krokowych. Sterownik przeszedł drobny lifting i obecnie wygląda tak, jak na II zdjęciu Software Dla funkcji rysowania, palenia laserem oraz grawerowania wykorzystano udostępniane na zasadach open-source oprogramowanie firmy Makeblock - mDraw, rozszerzony o funkcję sterowania przekaźnikiem. Natomiast dla aplikacja pick&place napisałem własny program, z funkcją odwrotnego liczenia kinematyki, oraz zamykania/otwierania elektrozaworu, co pozwala na zaprogramowanie pełnego cyklu "podnieś i przenieś". Składa się on z prostych procedur, typu PrzejdzDoPunktu(x,y), Chwyc(), Pusc(), SilownikZ(pozycja) i tak dalej. Trzecią oś swobody stanowi bowiem dla rysowania i grawerowania niewielka prowadnica podnoszona za pomocą linki przez serwo, natomiast przy chwytaniu podciśnieniowym wspomogłem się https://www.thingiverse.com/thing:3170748 Tak wygląda moduł generujący podciśnienie, wykorzystałem pompę próżniową Film - podsumowanie zawierające ujęcia z budowy oraz działania konstrukcji Robot otrzymał wyróżnienie na tegorocznych zawodach Robotic Arena oraz został zgłoszony do konkursu "Elektronika, by żyło się łatwiej". Przy okazji, pragnę podziękować mojemu sponsorowi - firmie MONDI Polska, która umożliwiła realizację całości projektu. Pozdrawiam, Wiktor Nowacki wn2001 (dla ścisłości - spostrzegawczy z pewnością zauważą rozbieżności w detalach pomiędzy różnymi zdjęciami oraz ujęciami z filmu - wykonałem je po prostu w różnym czasie, kiedy udoskonalałem jeszcze i poprawiałem konstrukcję )

Hej koledzy i koleżanki;-) Ci którzy są dłużej obecni na Forbocie mnie już trochę znają, ale dla nowych użytkowników których sporo ostatnio, krótki rys historyczny. Moje zainteresownie elektroniką zaczęło się w październiku 2017 roku od jakiejś nudy przy kompie kiedy to przeglądając neta natknąłem się na kursy Forbota. Długo sie nie namyślając zamówiłem najpierw kurs elektroniki podstawowy i od strzału dodatkowy, no i oczywiście zestaw tablic. Jako, że mnie to strasznie wciągnęło, dalej poszło za ciosem: technika cyfrowa i oczywiście kurs arduino poziom pierwszy i drugi . Wciągnęło niesamowicie, chyba głównie dzięki temu, że autorzy kursu potrafili swoją wiedzę przekazać jasno, klarownie i przede wszystkim ciekawie. Dobra koniec tej łzawej historyjki pora na opis projektu. Mój system zbudowany jest z: Arduino MEGA, nodeMCU z esp8266, czujnik zanieczyszczeń powietrza PMS5003; ethernet Shield do wyżej wymienionego, czterech czujników temperaturyDS18B20, dwa czujniki temperatury i wilgotności typu DHT11, jeden DHT22, czujnik ciśnienia i temperatury BMP280 I2C, moduł zegarowy RTC1307 I2C, enkoder z przyciskiem, wyświetlacz LCD 20×4 I2C, dwie listwy diod programowalnych po 4 szt, czujnik deszczu, buzzer bez generatora, moduł 8 przekaźników; kilka dodakowych przekaźników, radiolinia PIN4 Proxima 2szt, przekaźnik czasowy PCM-04 Zamel; kilka krańcówek, bramki logiczne OR; żaróweczka neonka, fotorezystor, kupa przewodów, rezystorów, diod itp., tablet, telefon. Działanie: Układ mierzy temperaturę w dwóch miejscach w domu, na zewnątrz temperaturę w słońcu, przy gruncie i 1m nad gruntem w cieniu. Dodatkowo mierzy ciśnienie atmosferyczne, wilgotność zewnętrzną i wewnętrzną oraz temperaturę wody w CO. Od niedawna także poziom zanieczyszczenia powietrza (budowę urządzonka pomiarowego przedstawię w kolejnym artykule). Zapamiętuje również, najwyższe i najniższe wartości każdego z czujników wraz z datą zdarzenia. Funkcją dodatkową jest alarm wywoływany przy pierwszych opadach deszczu, a także (na wyraźne życzenie żony) alarm informujący kiedy pralka w piwnicy skończyła pracę. Jeśli kogoś interesuje ta ostatnia funkcja odsyłam do mojego tematu na Forbocie. Główną funkcją układu jest sterowanie pracą 8 przekaźników obsługujących min. bramę, furtkę, oświetlenie. Każdy z przekaźników jest sterowany niezależnie: -sygnałem z arduino idącym przez bramki OR do których dochodzą także -sygnały z zewnętrznych włączników naściennych -radiolini sterowanych pilotem, - no i oczywiscie aplikacją BLYNK z telefonu, tabletu... Dopiero sygnał za bramką OR idzie do przekaźnika oraz dodatkowo jako potwierdzenie wraca do arduino. Dioda led na obudowie tabletu informuje o włączeniu przekaźnika także, kiedy tenże jest włączony „poza arduino” przez włącznik naścienny bądź radiolinię. Informacja o tym fakcie wraca do arduino powodując odpowiednie zmiany zmiennych i na bieżąco aktualizując diody led i informacje wyświetlane na LCD 20×4 oraz wyświetlaczu telefonu i tabletu w kuchni na ścianie będącego "centrum sterowania" całością. Wszystkie dane z czujników są na bieżąco wyświetlane i przewijane na LCD 20×4 który to wyswietlacz stał się dodatkowym(po tablecie) i zainstalowałem go w obudowie szafki zawierającej najważniejsze elementy układu. Po wciśnięciu przycisku enkodera wchodzimy w menu opcje gdzie możemy na LCD20x4 sprawdzić najwyższy i najniższy odczyt każdego z czujników, datę tego odczytu oraz zresetować pamięć dla każdego odczytu i czujnika z osobna. Możemy również tym enkoderem sprawdzić w menu stan przekaźników i nimi sterować. Wciśnięcie enkodera jest sygnalizowane przez buzzer. Osobną sprawą jest BLYNK który miał służyć początkowo tylko do kontroli przez telefon nad przekaźnikami, ale po poznaniu jego możliwości, całkowicie zmieniłem założenia i teraz to tablet z zainstalowanym Blynkiem jest głównym wyświetlaczem i sterownikiem całego układu. Trochę bliżej na temat aplikacji BLYNK w moim systemie możecie przeczytać tu. Na tablecie mam podmenu: przekaźniki, czujniki, max i min, historia, alarmy. W menu przekaźniki sterujemy z tableta i telefonu, w dowolnym miejscu na świecie, przekaźnikami, otrzymując z powrotem informację o faktycznym włączeniu przekaźnika(zmiana koloru widgeta oraz wyświetlonego na nim napisu).Ta informacja pojawia się także kiedy przekaźnik zostanie włączony przez kogoś innego(przez włącznik ścienny, radiolinia lub drugie urządzenie:tablet lub telefon). Choć poprzez udostępnienie tokena do naszego projektu takich urządzeń może być więcej. Drugie menu w BLYNK-uto wyświetlanie danych z wszystkich czujników odświeżane co 1 min, oraz małe „diody led” migające i informujące o prawidłowej komunikacji apka-arduino MEGA i apka-ESP(czujnik jakości powietrza). Kolejne menu to ekran z rozwijanym podmenu na którym wyświetlone są nazwy wszystkich czujników i poprzez wybór któregoś z nich możemy sprawdzić(podobnie jak to było na LCD20x4), najniższą i najwyższą wartość datę tego zdarzenia i zresetować pamięć dla każdego czujnika osobno. Następne menu to historia, czyli wykresy. Ja mam ustawione wyświetlanie na wykresach historii odczytów ciśnienia atmosferycznego, wigotności, temperatury CO, temperatury zewnętrznej, oraz osobny wykres dla czujnika jakości powietrza. Ostatnie menu w BLYNK-uto alarmy. Po pojawieniu się na odpowiednim pinie arduino sygnału z czujnika deszczu lub sygnału o końcu pracy pralki, na wyświetlaczu LCD20x4 przestaje się przewijać informacja o dacie, godzinie i odczytach z czujników, a wyświetla się info o alarmie z odpowiednią treścią, albo o pralce albo o deszczu. Dodatkowo listwy diod led migają na niebiesko(pralka) lub na czerwono(deszcz). Po wciśnięciu enkodera, wyłączeniu na tablecie lub telefonie albo upływie ustawionego czasu alarm wyłącza się. Informacja o alarmie pojawia się jako notyfikacja także na tablecie i telefonie, w sposób wizualny i dźwiękowy, poprzez wybraną melodię z pamięci talefonu/tableta. Ostatnio dołożyłem dodatkowo obsługę przekaźników głosowo poprzez Google Assistant. Jeśli kogoś bliżej interesuje ta kwestia to zapraszam tutaj. Kolejną miłą opcją jest podpięty do tabletu poprzez bluetooth wzmacniacz klasy D z pilotem spięty z głośnikami zainstalowanymi w kuchni. Google assistant pozwala na bezdotykowe, głosowe włączanie ulubionego przeboju z YT, radia itp. Co do przekażnika czasowego i krańcówek i przeakźników to mają one zastosowanie przy sterowaniu bramą garażową i oświetleniem garażu. Bramą garażową steruję z przycisku naściennego, pilotów radiowych, telefonu, tabletu. Jednak dodatkowo jest założony przekaźnik czasowy który po uplywie zadanego czasu zamyka otwartą bramę niezależnie od systemu. Również włącznik naścienny jest niezależny, więc nawet jak by sytem padł(co się nie zdażyło za ostatnie12 miesięcy) mogę sterować bramą. Krańcowki zainstalowane przy bramie podają informację do Aruduino, a te wysyła info do Blynka który informuje mnie notyfikacją, gdziekolwiek bym nie był, że właśnie została otwarta lub zamknięta brama garażowa. Kolejną sprawą jest automatyka oświetlenia garażu. Zrobiona "analogowo" tzn. jesli świeci się lampa z czujnikiem ruchu przed garażem, a brama jest calkowicie otwarta, zapala się całe oświetlenie garażu. Co znakomicie ułatwia nocne parkowanie. Chyba tyle. Aktualnie pracuję nad stroną internetową(dziękuję wszystkim cierpliwym webmasterom z Forbota za pomoc) postawioną na RPi, która będzie pokazywać światu jakie to fajne powietrze mamy w Kryrach;-). W planach też pomiar siły i kierunku wiatru. Gdyby ktoś chciał poczytać o początkach tego projektu to tutaj, a cały worklog jest tu. Cały sketch sterujący arduino i Blynkiem tutaj. Teraz kilka zdjęć i filmów. Wnętrze szafki z Arduino i całym osprzętem, płytka główna przed i po tuningu: "Centrum": Kilka slajdów z BLYNK-a: Wzmacniacz i głośniki w kuchni: Jeden film mówi więcej niż tysiąc słów więc: Prototyp: Aktualny: LCD dodatkowy: Jeszcze LCD z dołożoną obsługą PMS5003: Działanie BLYNK-a i przekaźników: BLYNK, "centrum", google assistant: Google Assistant w praktyce: Dziękuję za poświęcony czas i pozdrawiam wszystkich. Lajkujcie, subskrybujcie bądzcie moimi followersami i co się tam jeszcze robi

Swoją przygodę z elektroniką zacząłem kilka lat temu z celem zbudowania czworonożnego chodzącego robota. Nie bardzo sobie zdawałem wówczas sprawę ze stopnia skomplikowania tego zadania i śmieszy mnie dziś moja ówczesna naiwność, ale od tego czasu minęło parę lat i wiele się nauczyłem. W międzyczasie stworzyłem projekt taniego i łatwego w montażu robota, który opublikowałem pod adresem http://tote.rtfd.io, żeby nieco ułatwić zadanie innym. Naiwnie myślałem, że skoro dałem ludziom prosty punkt startowy, to teraz będą na jego bazie budować bardziej rozbudowane roboty i eksperymentować z platformą. Oczywiście myliłem się straszliwie, choć wiem o kilku konstrukcjach zainspirowanych moją. Dziś sam jestem dziadkiem^W^Wwiedząc więcej o tym jak to działa, postanowiłem zaprojektować zestaw do samodzielnego montażu oparty na podobnych pomysłach, ale bardziej mający formę gotowca. Zamiast optymalizować cenę postanowiłem tym razem zoptymalizować wygodę. Docelowo zamierzam zestaw sprzedawać częściowo zmontowany na Tindie. Dużo szczegółów konstrukcji pozostało z Tote. Nadal używam tanich serw SG90, które nadal zasilam bezpośrednio z baterii LiPo, kompensując za niskie napięcie większą częstotliwością sygnału sterującego. Nadal wykorzystuję fakt, że robot jest taki lekki, żeby przemycić nie do końca koszerne rozwiązania, jak wykorzystanie serw jako stawów nóg, bez dodatkowego podparcia, albo sklejanie ze sobą dwóch serw za pomocą hot glue. Ale tym razem nie używam taniego Arduino Pro Mini i C++, tylko mikrokontroler Atmel SAMD21 i CircuitPython. Nie ma już brzęczyka piezo na nóżce GPIO, tylko głośniczek podłączony do DAC. Do tego dodany jest akcelerometr dla prostego reagowania na ruszanie robotem i to tyle. Na górze jest header z nieużywanymi pinami do wpinania ewentualnych rozszerzeń — czujników lub dodatkowych serw czy światełek. Największą innowacją jest zrezygnowanie z użycia plastikowych orczyków od serw jako elementów konstrukcyjnych nóg, a zamiast tego płytka PCB zawiera, poza układem sterującym robota także wszystkie elementy mechaniczne. Sprawia to też, że łatwo możemy wymienić fragmenty nóg na inne, zawierające czujniki lub inne elementy elektroniczne. Programowanie, jak to w CircuitPythonie, odbywa się poprzez wgranie plików z kodem w Pythonie do robota, który po podłączeniu przez USB pojawia się w komputerze jako dysk. Możliwe też jest eksperymentowanie na żywo za pomocą konsoli pythonowej dostępnej po serialu. Robot jest pod względem mechanicznym w zasadzie ukończony, jak zwykle pozostaje jego zaprogramowanie, które pomimo wykorzystania języka wysokiego poziomu zajmuje mi sporo czasu — muszę się przyznać, że to nie ze względu na trudność problemu, ale na zmęczenie dzienną pracą i ciągłe odkładanie tego na później.

Niewątpliwie procesory, bądź mikroprocesory stanowią ogromną część elektroniki użytkowej. Prawie w każdym urządzeniu, poczynając od najprostszych, a kończąc na najbardziej zaawansowanych komputerach, najważniejsza jest jednostka centralna. Czasy największej świetności ośmiobitowe procesory mają już za sobą, ale nadal stanowią ważną część elektroniki. Wiele urządzeń nadal z nich korzysta. Moją przygodę z elektroniką cyfrową rozpocząłem od programowania mikroprocesorów firmy Atmel były to dokładniej procesory Atmega8 oraz Atmega328. Mimo wielkich możliwości jakie dają mikrokontrolery bardziej interesowała mnie strona hardware’owa tych układów. Na ich podstawie oraz procesorów takich jak Intel 4004, 8080 stopniowo poznawałem budowę oraz działanie mikroprocesorów. W pewnym momencie stwierdziłem że nie jest to takie trudne i sam zbuduję własny procesor. Był to DCE 4 (D-digital, C-computer, E-electronic, 4 ponieważ była to jednostka czterobitowa). Następnie rozpocząłem prace nad ośmiobitowym procesorem DCE 84. Jednak i on z upływem czasu wydał mi się bardzo prosty. Prezentowany mikroprocesor DCE 812 zaprojektowałem korzystając z rozwiązań zastosowanych w DCE 84 bazując na pełnej architekturze harwardzkiej (gdzie pamięć dla programu i danych jest fizycznie rozdzielona). Schemat blokowy układu można znaleźć poniżej. Do budowy zostały użyte podstawowe układy logiczne wykonane w technologii CMOS (przykładowo bramki AND) oraz gotowe układy pamięci RAM (UL6516 2k x 8bit) oraz ROM(dwa układy 28c64 8k x 8bit) , ponieważ budowa własnych pamięci nie była możliwa z powodu braku czasu i środków. Elementy takie jak ALU, układ sterowania, zegar, oraz obsługa pamięci i poszczególnych rejestrów roboczych została zaprojektowana przeze mnie od podstaw. Fizycznie układ powstał stosunkowo niedawno i nie obyło się bez komplikacji. Zmiana układu obsługującego pamięć RAM sprawiła, że układ działa zgodnie z założeniami. Pozwala on na wykonywanie podstawowych działań matematycznych oraz prostych programów stworzonych w języku C++ i przekonwertowanych na polecenia dla tego procesora. Najbardziej zaawansowanym programem, który udało mi się uruchomić było generowanie kolejnych liczb z ciągu Fibonacciego. Praca mikroprocesora zostaje rozpoczęta od wciśnięcia fizycznego przycisku RESET, który ustawia stan "0" na wyjściach wszystkich wewnętrznych rejestrów. Uzyskujemy poprzez to adres zero na wyjściu licznika rozkazów co powoduje rozpoczęcie pracy od pierwszego wprowadzonego rozkazu (lista rozkazów widoczna na zdjęciu poniżej). Następnie układ zaczyna liczyć od 0 do 15 wewnątrz układu sterowania do każdej z tych mikrooperacji przypisane jest odpowiednie działanie zgodne z rozkazem wprowadzonym do pamięci ROM może to być np. zapis do rejestru B, reset licznika rozkazów. Po wykonaniu wszystkich mikrooperacji licznik rozkazów zwiększa swoją wartość o jeden co skutkuje przejściem do kolejnego rozkazu i cały cykl wykonywany jest ponownie. Programowanie procesora realizowane jest poprzez odpowiednie przełączniki które umożliwiają przełączanie układu między stanem pracy a programowaniem. Wprowadzanie danych oraz wybieranie adresów również realizowane jest w ten sposób. Odpowiednie przełączniki służą również do sterowania zegarem procesora. Generowanie impulsów może odbywać się automatycznie z częstotliwością ok. 10Hz lub manualnie poprzez wciśnięcie przycisku. Obecnie projektuje kolejną wersje własnego procesora tym razem staram się wszystko umieścić w jednym układzie FPGA (Korzystam z tej płytki). Postępy w pracach można obserwować na moim blogu https://rafal-bartoszak.blogspot.com/ Dodatkowo wstawiam też link do filmu gdzie można zobaczyć działanie układu.

Witam! Chciałbym przedstawić wam moją konstrukcję, która stała się przedmiotem mojej pracy inżynierskiej. Mechanika: Konstrukcja mechaniczna w zasadzie oparta jest na 2 płytkach PCB. Do płytki głównej zamontowane są dwie kulki podporowe, a także silniki pololu o przekładni 1:10 co stanowi napęd robota. Z przodu zamontowana jest płytka z podstawą zawierająca uchwyty do czujników ultradźwiękowych. Taki sam uchwyt pod czujnik znajduje się również na 'ogonie' robota - jest on nie używany i został zamontowany eksperymentalnie. Na przedłużonej osi silników zostały zamontowane magnesy enkoderów magnetycznych co ilustruje poniższa fotografia. Elektronika: Sercem robota jest mikrokontroler AVR ATmega162, którego zadaniem jest sterowanie robotem w tym: obsługa enkoderów, sterowanie silnikami, odbiór informacji z mikrokontrolera slave nt. odległości mierzonych przez czujniki, realizację algorytmów sterowania, realizacja połączenia bluetooth, obsługa wyświetlacza LCD hd44780. Drugi mikrokontroler również AVR, ATmega328 realizuje tylko i wyłącznie obsługę czujników odległości HC-SR04. Pomiary normalizuje i wysyła interfejsem SPI do jednostki głównej ATmega162. Na pokładzie robota znajdują się również dwa enkodery magnetyczne AS5040 pracujące w pętli sterowania regulatora PI silników. Enkodery te pracują w trybie defaultowym czyli wyjście kwadraturowe, rozdzielczość 2x256. Silniki sterowane są poprzez mostek H L293. Komunikacją z robotem zajmuje się moduł bluetooth bt222 - czyli komunikacja jest przez UART mikrokontrolera. Główny mikrokontroler jest taktowany zewnętrznym kwarcem 16Mhz co przy takiej ilości obsługiwanych urządzeń i wykorzystywanych interfejsów było po prostu konieczne, z kolei mikrokontroler atmega328 jest taktowany zewnętrznym kwarcem jednak z powodu lepszej podstawy czasowej, która jest konieczna do dokładnych odczytów z czujników odległości. Na wyświetlaczu LCD są wyświetlane aktualnie mierzone wartości odległości czujników. Automatyka: Zostało wspomniane, że silnikami steruje algorytm regulatora PI. Aby obliczyć jego nastawy została przeprowadzona identyfikacja transmitancji. W tym celu wykorzystałem UART do przesyłania aktualnej prędkości silników oraz środowisko Matlab do wizualizacji danych na wykresie. Z wyliczeń wyszło, że silniki z zastosowanymi kołami mają transmitancję: G(s)=107/(0.19s+1) Po obliczeniu nastaw regulatora i zastosowaniu w praktyce okazało się, że można jeszcze troszkę dopieścić nastawy i ostatecznie wykresy odpowiedzi skokowej bez i z regulatorem wyglądają następująco: Software: Napisane w C w środowisku Eclipse. Umożliwia robotowi 3 tryby. Tryb avoid. W trybie tym robot ma za zadanie omijać przeszkody wykorzystując regulator rozmyty Takagi-Sugeno. Wykorzystuje w tym celu odczyty z czujników odległości. Tryb goal seeking. Robot podąża do celu czyli do odebranych przez bluetooth współrzędnych kartezjańskich podanych w [mm], zakładając, że miejsce od którego zaczyna lub dostał nowy zestaw współrzędnych, ma współrzędne 0,0. W trybie tym regulator Takagi-Sugeno ma za zadanie na podstawie zaimplementowanej odometrii oraz współrzędnych końcowych sterować robotem w celu osiągnięcia zadanego położenia. Problem algorytmu przedstawia ilustracja: Tryb avoid + goal seeking. Jest to połączenie dwóch wcześniej opisanych trybów. W trybie tym działają równocześnie obydwa wcześniej opisane algorytmy, jednak na wejście regulatorów PI sterujących silnikami jest podawany zbalansowany sygnał z obu algorytmów. Tzn w zależności od najmniejszej odległości od przeszkody mierzonej przez któryś z czujników jest obliczany procentowy udział wartości sterowania od dwóch algorytmów. Brzmi skomplikowanie ale takie nie jest. Najlepiej zobrazuje to wzór: V=K*Vg+(1-K)*Va gdzie V jest prędkością zadaną na regulator PI silnika, Vg jest prędkością wynikającą z algorytmu goal seeking, Va jest prędkością wynikającą z algorytmu avoid, K jest parametrem, który przyjmuje wartość z przedziału 0-1 w zależności od mierzonej minimalnej odległości do przeszkody. Robota wprowadza się w odpowiedni tryb za pomocą dwóch przycisków lub poprzez interfejs bluetooth. Odpowiednie tryby sygnalizują diody LED. W celu przesłania komendy zawierającej współrzędne celu najpierw należy wprowadzić robota w odpowiedni tryb, a następnie wysłać do niego wg stworzonego prze zemnie protokołu dane. Protokół wysyłania danych jest następujący: X±⌴⌴⌴Y±⌴⌴⌴& gdzie +- – znak współrzędnej, _ – wartość współrzędnej. Testy. Konstrukcja została przetestowana pod względem dokładności odometrii. Robot podczas licznych testów na bieżąco wysyłał swoje współrzędne, które w dalszej kolejności były obrabiane w środowisku Octave do przyjemnych w analizie wykresów. Przykładowy wykres drogi, którą pokonał robot na 'placu manewrowym' w trybie avoid: ... oraz rzut z góry na 'plac manewrowy': U góry pozycja początkowa, na dole końcowa robota. Cały ten obszar był dookoła ogrodzony ścianką. Słowa samokrytyki Co bym zmienił ? Czujniki. Ze względu na problematyczność wykrywania małych przeszkód lub gdy płaszczyzna przedmiotu uniemożliwia odbicie się fali ultradźwiękowej w stronę odbiornika. Zdarza się, że z powodu gubienia przeszkód robot po prostu w nie wpada. Najciekawsze fragmenty programu: Regulatory PI: //######################################## REGULATOR PRĘDKOŚCI ############################################ erra = vl-Va;//liczenie błedu prędkości errb = vp-Vb; if(ua<1023&&ua>-1023)Ca = Ca+(erra*dt);//całka błędu ua = kp*(erra + Ca/Ti);//regulator PI //P I if(ub<1023&&ub>-1023)Cb = Cb+(errb*dt);//całka błędu ub = kp*(errb + Cb/Ti);//regulator PI //P I if((ua<10)&&(ua>-10))ua=0; if((ub<10)&&(ub>-10))ub=0; motor_set(ua,ub);//ustawia sterowanie silników Regulator rozmyty Takagi-Sugeno trybu goal seeking: inline void PsiZ2Vlr(float *Psi, float *z, int16_t *vl,int16_t *vp) { float PSI[3]; float XL[6],XR[6]; float NR,FR,L,S,P,VL=0,VP=0,m=0; uint8_t i,k; ///////////////////////////////LICZENIE PRZYNALEŻNOŚCI////////////////////////////////// if(*z<=100)NR=-0.01*(*z)+1;else NR=0;//jak bardzo blisko jest cel if(*z<=100)FR=0.01*(*z);else FR=1;//jak bardzo daleko jest cel if(*Psi<=0)L=-0.3183*(*Psi);else if(*Psi<-M_PI)L=1;else L=0; if(*Psi<=0)S=0.3183*(*Psi)+1;else if(*Psi<-M_PI)S=0; else if(*Psi>M_PI)S=0;else S=-0.3183*(*Psi)+1; if(*Psi>=0)P=0.3183*(*Psi);else if(*Psi>M_PI)P=1;else P=0; /////////////////////////////////////TABLICA REGUŁ////////////////////////////////////// PSI[0]=L; PSI[1]=S; PSI[2]=P; //NR; XL[0]=-4000;XR[0]=4000; XL[1]=0;XR[1]=0; XL[2]=4000;XR[2]=-4000; //FR; XL[3]=-4000;XR[3]=4000; XL[4]=4000;XR[4]=4000; XL[5]=4000;XR[5]=-4000; /////////////////////////////obliczanie prędkości silników////////////////////////////// for(k=0,i=0;k<3;k++,i++)//pierwszy wiersz tabeli { VL+=NR*PSI[k]*XL[i]; VP+=NR*PSI[k]*XR[i]; m+=NR*PSI[k]; } for(k=0;i<6;k++,i++)//drugi wiersz tabeli { VL+=FR*PSI[k]*XL[i]; VP+=FR*PSI[k]*XR[i]; m+=FR*PSI[k]; } *vl=(int16_t)VL/m; *vp=(int16_t)VP/m; } Obsługa czujników odległości: //PRZERWANIE OD CAPTURE PIN ISR(TIMER1_CAPT_vect) { if( (TCCR1B & (1<<ICES1)) ) { LastCapture = ICR1;//jesli zbocze narastajace, zlap ICR1 } else { PulseWidth = ICR1 - LastCapture;//Jeśli zbocze opadajace oblicz PW pomiar=0;//wyzeruj flagę pomiaru } TCCR1B ^= (1<<ICES1);//Zmiana zbocza wyw. przerwanie } Mam nadzieję że robocik się podoba. W razie pytań proszę śmiało. Całości kodu nie udostępniam ze względu na prawa autorskie niektórych funkcji bibliotecznych. Co mogłem udostępniłem. Pozdrawiam was wszystkich !

Czytam te wpisy kolegi @xirtt i coraz bardziej się zastanawiam, czy to jeszcze forum o robotyce, elektronice, czy już portal randkowy. Ciągle tylko o miłości i miłości... A biorąc pod uwagę, że na portalu prawie sami faceci, to nawet wolę nie zgadywać w którą stronę ten portal zmierza.

@Treker a może to właśnie jest pomysł na "kolejny krok" portalu? Nie ograniczać się do samych kursów, ale przeprowadzać egazminy, czy testy i wydawać "certyfikaty"? Pewnie zabrzmi to bez sensu, ale może to pewien biznes-plan i kiedyś pracodawcy będą doceniali w CV ukończenie szkolenia Forbot-a? Co więcej odpowiednie egzaminy mogłyby ustalać rangę użytkownika na forum - co czasem oszczędzałoby pewnie wielu pytań.

Myślę, że nie warto spierać się o takie głupoty - jako inny przykład definicji dystrybucji linuxa polecam wiki: https://pl.wikipedia.org/wiki/Dystrybucja_Linuksa Tutaj mamy nieco lepiej zdefiniowane kryteria, bo pisanie o paru ludziach to chyba kiepski pomysł - w każdej nietrywialnej firmie znajdziemy paru ludzi, niektórzy nawet pracują. Pobieranie i używanie też nie nadaje się zbytnio - jako ciekawostkę podam, że yocto ma manager pakietów, do wyboru .deb, .rpm, .ipk oraz .tar - nie opisuję tego, ale pakiety są automatycznie tworzone i wystarczy je umieścić na serwerze. A co do jednego użytkownika to faktycznie na RPi moja dystrybucja ma jednego użytkownika - natomiast systemy nad którymi pracuję zawodowo mają znacznie więcej użytkowników. Wszyscy pobierają pakiety i z nich korzystają np. oglądając telewizję, chociaż wcale nie widzą że na pokładzie dekodera działa linux... Więc zostawmy może te spory językowe w spokoju - yocto to w rzeczywistości zestaw skryptów, coś jak make. Pozwala na skompilowanie relatywnie dużego systemu, a czy nazwiemy go dystrybucją, firmware-m, czy androidem to zostawmy lingwistom. A jak już się czepiamy słówek - formalnie Linux to samo jądro... Cała reszta to właśnie dystrybucja, czyli zestaw oprogramowania bazujący na GNU. Dlatego niektórzy puryści nazywają takie cudo GNU/Linux, natomiast to co mamy w telefonach Android/Linux. Zawartość karty SD Wracając do głównego wątku, czyli możliwości pracy z linuksem nieco inaczej niż przez instalację Raspbiana. Ostatnio wygenerowałem obraz systemu poleceniem bitbake core-image-minimal. Jak łatwo się domyślić jest to minimalny działający obraz, możemy go uruchomić ale praca na nim nie będzie pasjonująca. Jednak zanim przejdziemy dalej chciałbym zatrzymać się przez chwilę nad tym co taki minimalny obraz zawiera - skoro jest mały to łatwiej zrozumieć jak to działa. Tutaj pierwsza uwaga - wbrew pozorom działa już całkiem sporo rzeczy. Zawdzięczamy to jądru systemu - mamy minimalny zestaw oprogramowania, ale jądro oraz większość sterowników jest już na miejscu. Jeśli podłączymy np. wyświetlacz zobaczymy że działa - nawet bez x serwera. Wspominam o tym żeby zwrócić uwagę na pewną nadmiarowość pełnych dystrybucji. Okazuje się że system wbudowany może używać znacznie mniej pamięci i innych zasobów niż pełna wersja "desktopowa". Na karcie SD znajdziemy podobnie jak w przypadku Raspbiana dwie partycje: Pierwsza ma rozmiar "aż" 40MB i typ FAT32. Druga to główny system plików, który zajmuje raptem 12MB. Na pierwszej partycji znajdziemy firmware dla GPU Malinki (za chwilę do tego wrócę), bootloadery oraz obraz jądra linuksa. Druga partycja to raczej minimalistyczny system plików - znajdziemy na nim (dość sporą) bibliotekę języka C oraz BusyBox, czyli program udostępniający podstawowe polecenia powłoki (https://busybox.net/about.html). Warto zwrócić uwagę na znaczny rozmiar katalogu lib - to właśnie domyślna biblioteka C tyle zajmuje. W urządzeniach wbudowanych są popularne jej zamienniki, jak chociażby uclibc (https://www.uclibc.org/) - nie tylko są mniejsze, ale często szybciej działają. W każdym razie taka optymalizacja pojednczych MB to temat na osobny wątek. Jak startuje system Celem moich być może zbyt długich wpisów jest pokazanie jak korzystać z u-boot-a, jednak niejako przy okazji chciałbym wyjaśnić miejsce bootloadera w procesie uruchamiania komputera. Zacznijmy od czegoś prostego co wszyscy znają, czyli mikrokontrolera. Powiedzmy ATmega328 - po włączeniu zasilania następuje reset procesora oraz wykonywany jest program z pamięci Flash. Adres gdzie zaczyna się program jest znany (nie jestem pewien jaki, ale to chyba mało istotne). Nowy mikrokontroler ma pustą pamięć Flash, więc przed pierwszym zaprogramowaniem procesor wykonuje tylko instrukcje NOP (https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_NOP.html). Aby wgrać program konieczny jest sprzętowy programator - po zaprogramowaniu, program z pamięci Flash będzie wykonywany zaraz po załączeniu zasilania lub resecie procesora. Wszystko jest proste, ale wymaga dwóch istotnych elementów: pamieci flash oraz programatora. Konieczność posiadania programatora została elegancko rozwiązana w przypadku Arduino. Nowe mikrokontrolery są programowane za pomocą sprzętowego programatora i wgrywany jest do nich krótki program - nazywany właśnie bootloader-em. Przy kolejnych uruchomieniach procesora najpierw będzie zawsze działać bootloader. Wykona on sprawdzenie stanów odpowiednich pinów lub poczeka na dane przesyłane przez UART i jeśli wykryje odpowiednie sekwencje umożliwi programowanie pozostałej części pamięci flash. Natomiast podczas normalnej pracy urządzenia po prostu przekaże sterowanie do programu użytkownika. W pamięci flash przechowywane są więc dwa programy: bootloader oraz kod użytkownika. Jednak nie działają one równocześnie - bootloader rozpoczyna pracę, a następnie przekazuje sterowanie do głównego programu. Podobny schemat wykorzystywany jest w przypadku mikroprocesorów, chociaż jest nieco bardziej skomplikowany. Raspberry Pi jest pod tym względem nieco nietypowe - BCM2837 zawiera aż dwa procesory. Głównym wcale nie jest znany nam ARM, ale procesor graficzny, czyli VideoCore IV (https://en.wikipedia.org/wiki/VideoCore). Wiele osób takie rozwiązanie krytykuje, ale wcale nie jest ono aż tak nietypowe - spotkamy je również w świecie mikrokontrolerów, przykładowo przetworniki ADC mogą mieć wbudowany procesor (http://www.analog.com/en/products/aduc814.html), moduły radiowe często mogą wykonywać programy (http://www.ti.com/lit/ug/swru319c/swru319c.pdf), nawet popularny ESP8266 jest właściwie modułem radiowym który przypadkiem ma również procesor. Po załączeniu zasilania pierwszy startuje procesor graficzny, czyli VideoCore. Początkowy program jest zapisany w jego pamięci ROM - tutaj pojawia się pierwsza różnica między światem mikorkontrolerów i mikroprocesorów - ROM zamiast flash, to wbrew pozorom istotna zmiana. Jednak zasada jest identyczna - w ROM mamy bootloader, który wczytuje program. Różnica to liczba etapów. Na Arduino bootloader wczytywał od razu program główny, natomiast w przypadku mikroprocesorów najczęściej jest uruchamianych kilka bootloaderów, a dopiero na końcu właściwy program. Więc jako pierwszy uruchmia się bootloader zapisany w pamięci ROM - niewiele o nim wiadomo, większość producentów traktuje taki kod jako bardzo tajny. Ten bootloader potrafi obsługiwać karty SD oraz system Fat32. Stara się wczytać i uruchomić plik o nazwie bootcode.bin. Jak łatwo się domyślić, yocto pobrało odpowiedni plik z sieci i umieściło w obrazie, który nagraliśmy na karcie. Kolejny etap to wczytanie pliku start.elf. Nie jestem na 100% pewien, ale to chyba główny program dla VideoCore. Na naszej karcie znajdziemy jeszcze wersję start_x.elf z obsługą kamery RaspiCam oraz start_db.elf w wersji do debugowania (ale kodu i tak nie dostaniemy). Jest jeszcze plik start_cd.elf - nie wiem po co, może ktoś na forum wie do czego ta wersja służy? Pliki start.elf mają odpowiadajace im pliki z danymi, czyli fixup.dat, fixup_x.dat, fixup_db.dat oraz fixup_cd.dat. Wszystkie znajdziemy na naszej karcie SD - chociaż niepotrzebne możemy usunąć. Jeszcze dwa pliki są istotne dla uruchamiania malinki - config.txt oraz cmdline.txt. Oba są w formacie tekstowym, więc można użyć dowolnego edytora do ich zmiany. Pełnią funkcję ustawień, coś jak BIOS w stacjonarnym komputerze. Pierwszy jest bardzo rozbudowany, więcej o nim przeczytamy na stronie raspberrypi: https://www.raspberrypi.org/documentation/configuration/config-txt/README.md. Drugi zawiera parametry dla jądra systemu - używając u-boota nie będziemy musieli z niego korzystać. Teraz ostatnia i najważniejsza część - VideoCore ładuje z karty plik o nazwie kernel8.img do pamięci RAM oraz uruchamia rdzeń ARM tak aby wykonywał wczytany kod. Pewnie większość osób odgadnie, że kernel8.img to jądro systemu Linux - tak jest domyślnie, ale to wcale nie jest wymagane. Możemy napisać własny program, nazwać go kernel8.img i zostanie on uruchomiony bez Linux-a, czyli tak jak na Arduino. Jeśli lubimy takie ekstremalne rozrywki, polecam kurs programowania Raspberry Pi bez systemu operacyjnego: https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/, jest nawet wersja dla języka C zmiast asemblera (ale to takie niesportowe : http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/. W naszym przypadku kernel8.img to wcale nie jądro linuksa - jądro znajdziemy w pliku Image. Natomiast kernel8.img to u-boot, czyli kolejny bootloader: https://www.denx.de/wiki/U-Boot Konfiguracja przygotowana przez yocto startuje więc u-boota, który dopiero uruchamia właściwego Linux-a. W kolejnych wpisach pokażę do czego się to może przydać - wspomnę tylko że możliwości są spore, a przede wszystkim możliwe jest pobieranie obrazu przez sieć. Więc karta SD może być używana jedynie na początku uruchamiania systemu, podczas gdy wszystkie pliki przechowamy bezpiecznie na serwerze lub stacji roboczej.

Nixie - lampy od których nie można oderwać wzroku. Kiedyś podstawowy element do prezentowania danych, dzisiaj poszukiwany rarytas przez pasjonatów. Chciałem zaprezentować kilka zegarów jakie wykonałem swego czasu. Opiszę jeden konkretny, a na końcu pokażę kilka innych konstrukcji, które maja podobną elektronikę. Podstawowe funkcje Lampy LC-531 firmy DOLAM Format wyświetlania czasu HH:MM:SS Wyświetlanie daty Dwa niezależne czujniki temperatury DS18B20 Podtrzymanie bateryjne pracy układu zegara Prosta obsługa za pomocą pilota Programowany alarm z różnymi trybami powtórzeń Kilka melodyjek do wyboru jako dźwięk budzika Możliwość wł/wył zera z przodu Programowana częstotliwość „przewijania” lamp, w celu uniknięcia zatrucia katod Elektronika Zegar został oparty o mikrokontroler Atmega8 i zegar RTC PCF8563 . W urządzeniu można wyszczególnić kilka funkcjonalnych bloków: Zegar RTC przetwornica czujniki temperatury odbiornik IR multipleksowanie lamp Przetwornica oparta jest o poczciwego NE555, a jasność lamp reguluje się potencjometrem. Do zegara można podłączyć dwa czujniki temperatury, a odczytana z nich wartość będzie wyświetlana co kilkadziesiąt sekund. Do sterowania wykorzystany jest malutki pilot na podczerwień. Zegar posiada zaprogramowanych kilka melodyjek monofonicznych, które można ustawić jako dźwięk budzika. Użyłem do tego celu buzzer bez wbudowanego generatora. Fajną opcją jest tzw. “slot machine”, czyli krótkie przewijanie wszystkich cyfr, głównym celem tego zabiegu jest ochrona lamp przed zatruciem katod, zwłaszcza pierwszych lamp, gdzie cyfra nie zmienia się przez wiele godzin, szczególnie w zegarach gdzie wyświetlana jest tylko godzina. Efekt przewijania cyfr jest włączany co pięć minut i trwa 10 sekund. Jest to efekt naprawdę miły dla oka. Lampy są aktywowane za pomocą wysokonapięciowych tranzystorów z serii MMBT, a poszczególne cyfry z wykorzystaniem modułu 74141. Układ 74141 jest dekoderem kodu BCD na kod dziesiętny, który zaprojektowano specjalnie do sterowania lampami z zimną katodą. Obudowa W tym konkretnym egzemplarzu wykonana została z poczciwej zabejcowanej sosny. Całość została zamknięta pod pleksą, która była wygięta na ciepło zwykła opalarką. Płytka z elektroniką jest wyeksponowana, widać wszystkie elementy, a PCB jest zabezpieczone prostą soldermaską wykonaną z farby termoutwardzalnej. Schemat Niżej zamieszczam zdjęcia kilku innych zegarów jakie wykonałem, schemat elektroniczny jest w nich podobny.

Witajcie! Mam przyjemność przedstawić mojego "nowego" robota minisumo - Predator. Stworzyłem go mianowicie w II Liceum (2016-17) ale jako, że jest teraz czas sesji to jako wzorowy student postanowiłem go tutaj opisać. Koncepcja, projektowanie konstrukcji i późniejsze jej wykonanie oraz zaprogramowanie układu sterującego zajęło do 6 miesięcy. Robot wziął udział w swoim pierwszym turnieju na Cyberbocie w Poznaniu, po czym przeszedł na urlop aż do obecnego roku gdzie wziął udział w Robotic Arenie we Wrocławiu. Mechanika: Konstrukcja składa się głównie z laminatu i stali. Podwozie robota zbudowane jest z 2 płyt 10x10 (z docięciami na koła i śruby) o szer. 2mm i 3mm jedna na drugiej, przy czym na końcu ostatniej zamocowane jest ostrze kupione jako "nóż do strugarek HSS". Reszta obudowy to laminat zlutowany ze sobą i połączony śrubami z elektroniką i podwoziem. Obudowa pomalowana czarnym sprayem (głównie dla estetyki, ale też aby był cięższy do wykrycia). Napęd w robocie stanowią 2 silniki micro Pololu 50:1 a sterują nimi 2 mostki H TB6612. Felgi zostały zrobione na zamówienie przez użytkownika HungryDevil, a opony są odlane z silikonu. Sam projekt był tworzony w Inventorze, niestety wraz z rozpoczęciem studiów zmieniłem komputer, a stary był sformatowany Elektronika: Płytki PCB zaprojektowane zostały w programie Eagle i wytrawione domowymi sposobami. Sercem robota jest Atmega328P w wersji SMD. Układy zasilane są z LiPo'la 2s, 20c, 3,85Wh przez stabilizator liniowy 5V 7805. Czujnikami zastosowanymi do wykrywania przeciwnika są legendarne cyfrowe czujniki Sharp 40cm w liczbie czterech. Planowane były również czujniki linii, jednak płytki z czujnikami nie działały przed zawodami tak jak powinny także usunąłem je na czas zawodów Cyberbot. Ich implementacja miała się odbyć tuż po zawodach, ale z dzisiejszej perspektywy po 2 latach mogę powiedzieć, że raczej Predator się ich już nie doczeka Na górnej płytce, oprócz wejścia programatora i wejścia na moduł startowy, znajdują się przełączniki, których zadaniem miało być wyłączanie/pomijanie czujników które doznały awarii podczas walki (w praktyce nie użyte ani razu). Software: Program napisany w Atmel Studio. Raczej nie należy do zaawansowanych i w głównej mierze został wykonany metodą prób i błędów. Strategia robota to często używane tzw. "Tornado". Robot obraca się dopóki nie wykryje przeciwnika a po jego znalezieniu, rusza prosto na niego. Podsumowanie: Predator nie do końca wyszedł w taki sposób jaki miał. Posiada sporo wad, jako główną podałbym oczywiście brak czujników podłoża. Dodatkowo niedokładność konstrukcji spowodowała delikatne wystawanie przednich czujników poza obudowe. Mimo tego jestem bardzo zadowolony z niego, ponieważ jest to dopiero mój drugi robot, którego zbudowałem. Mam nadzieję, że ten post pomoże innym początkującym konstruktorom. Osiągnięcia: I miejsce na XI Robotic Arena 2019 we Wrocławiu Tu dorzucam jeszcze parę dodatkowych zdjęć: Pozdrawiam i do zobaczenia na kolejnych zawodach, Paweł

A co tu pisać... Ivona to nie jest, zwykły syntezator Klatta, trochę uproszczony (wywalone filtry dla 16 kHz), przystosowany do naszego pięknego języka i przełożony na C++. Kod jest na https://github.com/ethanak/ESP8266-Lektor - muszę poprawić README.md bo się lekko zdezaktualizowało (autorzy uprzejmie poprawili babola w funkcjach i2s). Karmi się go tekstem w utf-8, potrafi sterować np. paskiem led lub serwem od szczęki, może generować predeklarowane kształty ust. Da się skompilować pod Linuksem żeby posłuchać jak gada. Co do dokumentacji... chyba faktycznie coś skopali, bo nie mogę znaleźć paru rzeczy które kiedyś same się pchały w oczy.

Cześć Od pewnego czasu projektuje system do zarządzania smart domem i urządzeniami IoT oraz asystenta głosowego. Założenia mojego projektu to asystent ma być po polsku cała instalacja i konfiguracja ma być banalnie prosta - wszystko możliwe do edycji w intuicyjnym gui poprzez stronę internetową Co już działa? Można dodawać własne intencje po jakich asystent interpretuje naszą wypowiedź i wybrać działanie jakie ma wykonać (obecnie podajemy link na api jakie ma rzucić requesta, czyli na przykład może wyłączyć jakiś przekaźnik, zapalić led na dany kolor itp) Można dodawać własne czujniki, które będą widoczne w gui z możliwością edycji tekstu, ikon i koloru. Parę screenów z wyjaśnieniami: powyżej Widoczne czujniki. Dane odbierają bardzo prosto: czujnik(ten, że tak powiem bardziej fizyczny) musi wysłać na api requesta w stylu ip/sensors/nazwaCzujnika/wartość (nazwa oczywiście wybrana i edytowalna przez nas), zatem przez espEasy da się do ogarnąć Poza tym wartości w danych 'kafelkach' odświeżają się same z siebie (bez przeładowania całej strony oczywiście), także zawsze dane są aktualne. Te nieprzyjemne dla oka nazwy typu textTopRight są po to by było widać które pole z formularza któremu polu odpowiada. Tekst na środku największą czcionką to tytuł. Dodatkowo można prawie w każdym z tych miejsc dodać ikonę (poprzez formularz w jednym ze sceenów niżej) dowolną z https://fontawesome.com/icons?d=gallery podając po prostu jej class, czyli w przypadku https://fontawesome.com/icons/comment?style=solid będzie tam trzeba umieścić: fas fa-comment. powyżej podgląd konfiguracji. Jak widać można ustawić jakie urządzenia mają znaleźć się w zdaniu, jakie intencje, czy ma wychwytywać kolory.. W Pierwszym przykładzie (id1) (teraz tylko zauważyłem - tutaj do poprawnego działania pole Colors powinno być true )wyrażenie by zmienić led na kolor czerwony mogłoby brzmieć: "Zapal led na kolor czerwony" lub "uruchom led na niebiesko". By wyłączyć led należałoby powiedzieć "wyłącz led' Tu widać formularz dodawania Czujnika. Asystent głosowy wyłapuje keyword za pomocą Snowboya, mowę zamienia na tekst i zbiera z niego intencje dzięki wit.ai, a interpreter konkretnych intencji to już system napisany przeze mnie w javie. Chciałbym w przyszłości dodać możliwość tworzenia własnych motywów graficznych gui. Obecnie do dodania obsługa asystenta głosowego bezpośrednio na stronie (obecnie działa on jako osobna aplikacja python3) i sporo innych rzeczy. Na przykład wykresy z grafany. Pytanie ode mnie co sądzicie? Czy ktoś ewentualnie chciałby potestować gdy wydam w miarę stabilną i bardziej funkcjonalną wersję? Docelowo chciałbym by wszystko uruchamiało się z dockera.

Ja rozumiem trochę problem z tworzeniem "pustych" działów. Chciałbym sam widzieć na tym forum więcej postów na ten temat, ale wydaje mi się, że samo założenie działu tu nie pomoże. Sam niestety na ten temat nic nie napiszę. Być może powinniśmy spróbować po prostu pisać na ten temat na razie gdziekolwiek, a jak się uzbiera więcej postów, to się założy dział. Z drugiej strony, jakby w ten sposób tylko zakładać działy, to mielibyśmy w zasadzie dwa: "nie działa mi" i "potrzebuję program".