Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 7 punktów
    Artykuł przeznaczony do wszystkich zapaleńców druku 3D. Można nie kupować dość drogi filament do swojej drukarki 3D, a produkować w domu własny filament z zużytych butelek PET od napojów. Przy tym nieważne, jeżeli butelka jest pognieciona, ona również się nadaje do domowej produkcji filamentu. Filament z butelek ma sporo zalet w porównaniu z firmowym filamentem kupowanym – ABS albo PLA. Przede wszystkim, że produkowany filament nic nie kosztuje, jest po prostu darmowy Produkowany pręt filamentu Jest bardzo sztywny i absolutnie nie łamliwy, wytrzymuje sporo ostrych przegięć. Filament własnej produkcji jest sporo mocniejszy i twardszy, jak na rozciąganie tak i o wiele bardziej odporny na uderzenie. Absolutnie nie pochłania wody, czyli nie trzeba go ani suszyć, ani chronić w zamkniętym zabezpieczonym od nawilżania się opakowaniu. Praktycznie nie skurcze się przy ochłodzeniu w trakcie druku. Nie wymaga chłodzenia drukowanej warstwy. Nie wymaga stołu podgrzewanego. Dla przyczepności wystarczy miejsce na stole posmarować cienką warstwą kleju w sztyfcie na przykład typu „Glue Stick” Wydrukowane detal można obklejać od razu po skończeniu wydruku. Taki filament jest bardzo odporny na działanie rozpuszczalników i środków chemicznych. Jak widać filament produkcji własnej ma sporo zalet w porównaniu z filamentami kupowanymi, a najważniejsze – że jest darmowy. Niżej przedstawiono zdjęcia maszynki do produkcji filamentu: Do domowej produkcji filamentu wykorzystywane zużyte butelki od napojów. Ale butelki muszą być czyste, resztki kleju do nalepki powinni być usuwane. Technologia produkcji jest bardzo prosta i składa się z trzech następujących operacji: Poprawa zgniecionych butelek i butelek z ryflowaną powierzchnią tak, żeby ścianka boczna butelki była gładka. Nacinanie butelek na paski o określonej szerokości, od 5mm do 12mm w zależności od grubości ścianki butelki. Produkcja pręta filamentu z nacinanych pasków na specjalnej maszynce z nawijaniem na bębenek odbiorczy. Na tych wideo można obejrzeć prace maszynki i przyrządu do nacinania pasków z butelek: Zębatka drukowanie:
  2. 7 punktów
    Jakiś czas temu na forum pojawiło się kilka wpisów krytykujących Raspberry Pi jako platformę sprzętową. Nie próbuję nawet wmawiać, że malinka jest idealna - jednak niektóre problemy można rozwiązać bardzo (albo chociaż dość) łatwo. Problemy o których piszę to np. zużywanie kart SD, długi czas uruchamiania płytki, problemy z systemem plików jeśli nagle odłączymy zasilanie, długi czas kompilacji programów, czy brak możliwości uruchomienia systemu z pamięci USB. Wiele z opisanych niedogodności wynika ze sposobu używania malinki. Większość osób stara się zrobić z niej mały komputer PC - i nie ma w tym nic złego, w końcu na Forbocie właśnie tak opisywaliśmy kurs Raspberry Pi. Jednak malinka nie we wszystkim może zastąpić komputer stacjonarny i czasem nieco inne podejście może dawać nieco lepsze rezultaty. Komputer stacjonarny, a komputer wbudowany Pierwsza istotna sprawa to rozróżnienie między rozwiązaniami wbudowanymi (embedded), a komputerem stacjonarnym (desktop/laptop). Urządzenia wbudowane są konstruowane do spełniania jednej, z góry określonej funkcji - przykłady to procesor w ekspresie do kawy, bankomacie, czy samochodzie. Oprogramowanie można aktualizować, nawet zmieniać na własne (tym zajmują się hackerzy), ale nadal program ma ściśle określone zadanie do wykonania. System ogólnego przeznaczenia, to nasze komputery stacjonarne lub przenośne - czyli zupełne przeciwieństwo wbudowanych. Można na nich grać w pasjansa, Wiedźmina, a nawet inne gry, przeglądać internet, pisać programy i robić miliony innych rzeczy. Instalacja nowych programów jest łatwa, niekiedy nawet udaje się je odinstalować. Arduino jest kolejnym przykładem platformy wbudowanej. Program kompilujemy na PC, wgrywamy na płytkę i ma on wykonywać to co sobie zaplanowaliśmy - migać diodą, sterować robotem, itd. Ale już nowych progamów nie dodamy, nie będziemy na Arduino kompilować kodu, ani grać w pasjansa (chyba że to jest główna funkcja naszego układu). Raspberry Pi natomiast jest najczęściej używane jako mały komputer PC. Instalujemy na karcie SD Raspbiana (lub inną dystrybucję) i dalej używamy tak samo jak komputer stacjonarny. Może gier jest mniej, ale minecraft działa całkiem fajnie, RetroPie pozwala na emulację starych komputerów i konsol, a użwanie kompilatora (np. gcc) nikogo nie dziwi. Raspberry Pi całkiem dobrze sobie z takimi zadaniami radzi, ale to wbrew pozorom nadal głównie komputer wbudowany. W niniejszym artykule chciałbym chociaż wprowadzić w nową opcję, czyli użycie malinki jako komputera wbudowanego - mającego jedno zadanie, które dobrze wykonuje. System operacyjny Wszyscy wiemy jak działa Raspberry Pi - na karcie SD mamy ulubioną dystrybucję, kartę umieszczamy w czytniku, podłączanie zasilanie, czekamy, chwilę jeszcze czekamy, a może jeszcze jedną chwilę... i mamy pulpit z ikonkami albo chociaż konsolę do wydawania poleceń. Programy pobieramy z sieci (repozytorium), apt jest prosty i sympatyczny w użyciu. A gdybyśmy tak spróbowali przygotować własną, mniejszą ale dopasowaną do naszych potrzeb wersję systemu? Okazuje się że nie jest to aż tak trudne (chociaż proste też nie jest), w nagrodę będziemy za to mogli pozbyć się problemów o których wspominałem na początku artykułu. Yocto Własną dystrybucję Linux-a można przygotować zupełnie od podstaw - zaczynając od kompilacji kompilatora. Jest to jednak dość złożony proces, świetny do nauki, ale niekoniecznie wygodny. Na szczęście znajdziemy gotowe projekty przygotowujące naszą dystrybucję linuksa od podstaw. Buildroot (https://buildroot.org/) jest jednym z takich projektów - pozwala on na łatwe wybranie potrzebnych nam programów oraz ich skompilowanie ze źródeł. Ostatnio coraz większą popularność zyskuje jednak inny projekt - Yocto (https://www.yoctoproject.org/). Działa o wiele wolniej niż buildroot (jak to z narzędziamy opartymi o Pythona bywa), ale lepiej sprawdza się w dużych projektach. W następnym wpisie postaram się opisać jak można użyć Yocto to przygotowania własnej wersji systemu dla malinki. Jeszcze dwa słowa odnośnie buildroot-a. Dawno, dawno temu opisywałem jak użyć go podczas instalowania linuksa na netbook-u domyślnie pracującym z Androidem: https://forbot.pl/blog/sprawdz-jak-tanio-zbudowac-robota-z-systemem-linux-id7751 To co chcę teraz opisać to bardzo podobne rozwiązanie, ale zamiast netbook-a jest Raspberry Pi, a rolę Androida zajmuje Raspbian. No i po tych kilku latach yocto uzyskało pewną przewagę na buildrootem, więc też będzie użyte. Szybki start Żeby nie zanudzić najpierw szybki i dość ogólny opis. Celem będzie utworzenie podstawowego obrazu systemu, z którego wystartuje malinka. Najpierw należy przygotować odpowiedni komputer PC oraz system operacyjny. System to oczywiście Linux - wspierane są dystrybucje Debian, Ubuntu, Fedora, OpenSUSE oraz CentOS. Prawdopodobnie użycie innej dystrybucji jest też możliwe, może jednak wymagać dodatkowych kroków. W zależności od posiadanej wersji musimy zainstalować odpowiednie pakiety oprogramowania, wszystko znajdziemy opisane tutaj: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#required-packages-for-the-host-development-system Yocto można używać w systemie Windows lub MacOS wykorzystując maszynę wirtualną. Jednak takie rozwiązanie ma znaczącą wadę - bardzo spowalnia i tak czasochłonną kompilację obrazu systemu. Nie polecam takiego rozwiązania, lepiej używać natywnego linux-a i poszukać możliwie mocnego komputera - 4 rdzenie to raczej minimum, ale yocto potrafi nawet 44 wykorzystać (tyle testowałem), więc im silniejszy komputer tym lepiej i szybciej - a maszyny wirtualne pod względem wydajności niestety nie oszałamiają. Oprócz szybkiego procesora o możliwie wielu rdzeniach, będziemy potrzebowali również sporo miejsca na dysku. Minimum to ok. 30 GB, ale nieco bardziej rozbudowana konfiguracja może potrzebować i 100GB. Oczywiście szybki dysk ma swoje zalety, więc jeśli mamy miejsce na dysku SSD, warto go użyć. Ja wykorzystuję dysk SSD podłączany przez USB. To całkiem wydajne rozwiązanie, a możliwość odłączenia dysku od stacji roboczej i podłączenia do laptopa bardzo się przydaje. Dlatego u mnie ścieżka do projektu jest nieco długa: /mnt/usbssd/raspberry/yocto W tym katalogu należy pobrać sam projekt yocto, czyli wykonać: git clone -b sumo git://git.yoctoproject.org/poky.git Potrzebne będą jeszcze dwie tzw. warstwy, czyli powiedzmy biblioteki: meta-openembedded oraz meta-raspberrypi. Pobiera się je poleceniami: git clone -b sumo git://git.yoctoproject.org/meta-raspberrypi git clone -b sumo git://git.openembedded.org/meta-openembedded Teraz w katalogu /mnt/usbssd/raspberry/yocto znajdziemy trzy podkatalogi: poky, meta-raspberrypi, meta-openembedded. Pierwszy z nich jest dla nas najważniejszy więc wchodzimy do niego, a następnie wczytujemy zmienne ze skryptu oe-init-build-env: cd poky source oe-init-build-env Na ekranie widzimy podpowiedź co zrobić dalej, jednak zanim do tego przejdziemy musimy poprawić domyślną konfigurację yocto. Plik conf/bblayers.conf zawiera listę wybranych wartstw (bibliotek). Musimy dopisać używane przez nas, dopisujemy więc: BBLAYERS ?= " \ /mnt/usbssd/raspberry/yocto/poky/meta \ /mnt/usbssd/raspberry/yocto/poky/meta-poky \ /mnt/usbssd/raspberry/yocto/poky/meta-yocto-bsp \ /mnt/usbssd/raspberry/yocto/meta-raspberrypi \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-oe \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-multimedia \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-networking \ /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-python \ " Kolejny krok to edycja głównego pliku konfiguracyjnego o nazwie conf/local.conf. Domyślnie zawiera on dużo komentarzy, uproszczona wersja wygląda następująco: MACHINE = "raspberrypi3-64" DL_DIR = "${TOPDIR}/downloads" DISTRO ?= "poky" PACKAGE_CLASSES ?= "package_ipk" EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" CONF_VERSION = "1" RPI_USE_U_BOOT = "1" ENABLE_UART = "1" Pierwsza linia ustala typ naszej "maszyny", czyli Raspberry Pi 3 w wersji 64-bitowej. Jeśli używamy innej wersji, musimy odpowiednio zmodyfikować ten wpis. Co ciekawe cała dystrybucja będzie wykorzystywała ustawienia zoptymalizowane dla naszgo procesora - domyślnie Raspbian jest kompilowany tak, aby programy działały na najmniejszym wspólnym mianowniku, czyli starym Raspberry 1 - używając yocto nie tylko jądro, ale i cały system zostanie skompilowany pod nasze potrzeby. Nie zadziała na starszych płytkach, ale na naszej wykorzysta jej potencjał. Kolejny ważny parametr to ustawienie RPI_USE_U_BOOT. Dzięki niemu zostanie użyty bootloader u-boot, co pozwoli na załadowanie systemu przez sieć (TFTP), podłączenie dysku sieciowego (NFS), albo nawet użycie pamięci USB. Jest to pierwszy etap pozwalający na pozbycie się usterek na które wiele osób narzeka. W tym pliku można również wymusić użycie systemu "tylko do odczytu". Jedna dodatkowa linijka i karta SD będzie działać prawie w nieskończoność - do tego wrócimy później. Na razie czas zacząć kompilację i zrobić sobie (długą) przerwę. Wydajemy polecenie: bitbake core-image-minimal Yocto pobierze z sieci źródła wszystkich programów a następnie je skompiluje. Taki proces wymaga szybkiego łącza i trwa... od 20min do 4h. Na szczęście później jest już szybciej, ale za pierwszym razem można sobie zrobić przerwę na lunch. Po zjedzeniu lunchu, albo chociaż przerwie mamy gotowy obraz naszego systemu. Wynikowe pliki znajdziemy w katalogu tmp/deploy/images/raspberrypi3-64: Tym co na początek nas zainteresuje to plik z gotowym obrazem całej karty SD, czyli core-image-minimal-raspberrypi3-64.rpi-sdimg. Warto zwrócić uwagę na wielkość obrazu - u mnie wyszło 56 MB. To nadal bardzo dużo, ale domyślny Raspbian wymaga kilku GB. Kartę SD przygotujemy poleceniem dd, u mnie urządzenie /dev/sdh odpowiada karcie, więc polecenie: sudo dd if=tmp/deploy/images/raspberrypi3-64/core-image-minimal-raspberrypi3-64.rpi-sdimg of=/dev/sdh bs=4M Pozwala na nagranie obrazu na nośnik. Teraz można umieścić kartę w czytniku Raspberry Pi i wystartować system: Uruchomienie sytemu zajmuje znacznie mniej czasu niż w przypadku domyślnego systemu. To nadal bardzo daleka od optymalnej konfiguracja, ale i tak linux jest gotowy do pracy w kilka sekund. To co otrzymaliśmy to pierwsza, minimalna wersja systemu - mała ale zoptymalizowana dla naszego sprzętu. Nie znajdziemy na niej minecrafta, ani nawet interfejsu graficznego, ale to co wybraliśmy działa szybko i wydajnie. Mając taki system jako punkt wyjścia możemy przygotować bardziej rozbudowaną wersję, wyposażoną w potrzebne nam programy i biblioteki. Warto natomiast zwrócić uwagę na nieco inny sposób pracy z systemem. Całą kompilację wykonujemy na komputerze stacjonarnym, malinka tylko wykonuje przygotowane programy. Działa więc tak jak Arduino, a nie typowy Raspbian.
  3. 7 punktów
    Witajcie! Bolt to robot klasy Linefollower Standard. Został zaprojektowany, zbudowany oraz zaprogramowany przez kolegę Hubert.M oraz mnie. Jest on naszą najnowszą konstrukcją. Konstrukcja mechaniczna. Robot składa się z 2 płytek PCB, wykonanych przez firmę SATLAND Prototype. Płytki połączone są dwiema węglowymi listewkami, a z tyłu robota znajduje się aluminiowa podpórka zabezpieczająca przed przewróceniem się robota. Podpórkami listwy czujników są tranzystory w obudowie TO92. Silniki użyte w robocie to popularne Pololu HP 10:1. Koła wykonał dla nas hungrydevil. Masa robota z baterią wynosi 69 gramów. Elektronika. Zdecydowaliśmy się na mikrokontroler STM32F103C8T6. Silniki sterowane są układem TB6612. Zastosowane czujniki linii to KTIR0711. Czujników na chwilę obecną jest 9. Zastosowaliśmy moduł bluetooth HC-05. Zastosowanie modułu znacznie ułatwiło strojenie robota. Ponadto stan każdego czujnika jest odzwierciedlony diodą LED. Robot zasilany jest pakietem Li-pol o pojemności 150mAh. Część logiczna robota zasilana jest napięciem 3.3V. Program. Algorytm robota jest napisany w języku C. Zastosowano regulator PD. Dzięki modułowi BT wszystkie nastawy regulatora mogą być ustawiane bez ponownego programowania robota. Ponadto, program pozwala na np. zdalne sterowanie robota po połączeniu z komputerem. Do zażądania robotem napisaliśmy 2 aplikacje – na telefony z systemem android, aplikacja pozwala na wystartowanie robota, a także na jego zatrzymanie. Z Kolei aplikacja na PC oprócz podstawowej funkcjonalności pozwala na dobieranie nastaw robota. Ponadto można za jej pomocą rysować wykresy uchybu i pochodnej z uchybu. Bolt ma brata bliźniaka, o nazwie Bez Nazwy. Jest on nieco szybszy od Bolta (bo czerwony). Osiągnięcia i plany na przyszłość. - 2 miejsce na Konkursie robotów SEP Gdańsk 2015 - 4 miejsce na SUMO Challenge 2015 W robocie planujemy jeszcze bardziej poprawić jakość sterowania, oraz rozważamy wykonanie węższej listwy czujników z czujnikiem odległości, aby móc startować w kategorii LF Enhanced. Film z przejazdu:
  4. 6 punktów
    Od dawna interesowały mnie pomiary warunków meteorologicznych w mojej miejscowości, pierwsza stacja meteorologiczna, którą zbudowałem około roku 2010, wykonana była na mikrokontrolerze Atmega32. Do komunikacji z światem wykorzystywała moduł LAN Wiznet 7010a. Stacja ta była oprogramowana w języku BASCOM. Projekt który chcę zaprezentować dzisiaj działa już od roku 2018 i został oprogramowany w środowisku Arduino. Stacja została podzielona na 2 moduły, pierwszy pomiarowy oparty jest na klonie Arduino Nano oraz drugi odbiorczy którego sercem jest ESP8266 NodeMCU v3, służy on również do wyświetlania aktualnych pomiarów na wyświetlaczu LED dot matrix o wymiarach 8x56 punktów. Na pracach stolarskich się nie będziemy skupiać napiszę tylko że klatka meteorologiczna została wykonana z drewna sosnowego i umieszczona na wysokości 2 m. Moduł Pomiarowy Czujniki jakie zastosowałem to dwie sztuki DS18B20 pierwszy zajmuje się pomiarem temperatury przy gruncie na wysokości 5cm, drugi pełni rolę zapasowego czujnika temperatury na wypadek uszkodzenia się głównego czujnika BME280. Do pomiaru prędkości wiatru wykorzystuję wiatromierz firmy Maplin na jeden obrót wiatromierza przypadają 2 impulsy z kontaktronu który jest w nim zamontowany, producent dostarcza również odpowiedni wzór według którego można obliczyć rpm oraz prędkość wiatru w km/h. Dane mierzone przez wiatromierz możemy podzielić na dwie wartości, pierwsza to chwilowa prędkość, druga prędkość w porywach, aby uśrednić wartości mierzone program zlicza impulsy z 5s a następnie dokonuje odpowiednich obliczeń. Zebrane dane przesyłane są do drugiego urządzenia poprzez moduły radiowe które działają na częstotliwości 433,92 MHz. W tym celu zastosowana została biblioteka RCSwitch. Każda mierzona wartość jest wysyłana jako osobna transmisja. aby rozróżnić pomiary z konkretnych czujników mierzona wartość mnożona jest przez 100 a następnie dodawana jest liczba 100 000 dla pierwszego czujnika, 200 000 dla drugiego itd. Przykład kodu który realizuje tę funkcję poniżej: // temperatura sensor BME codetosend = temp * 100 + (1 * 100000); mySwitch.send(codetosend, 24); // wilgotnosc sensor BME codetosend = hum * 100 + (2 * 100000); mySwitch.send(codetosend, 24); Moduł Wewnętrzny Obudowa, która idealnie nadawała się do implementacji wewnętrznego modułu pochodzi z tunera IPTV Motorola VIP1910-9. Przedni panel został wykonany z ciemnego półprzepuszczalnego plastiku który idealnie nadaje się do umieszczenia w nim wyświetlacza. Sercem urządzenia jest układ ESP8266. "Moduł wewnętrzny" został również wyposażony w czujnik temperatury oraz wilgotności DHT22, dodatkowo w celu prezentacji zmierzonych wartości dołączone zostało 7 szt. modułów wyświetlacza LED dot matrix z układem MAX7219. Do obsługi tej matrycy zastosowałem bibliotekę Max72xxPanel.h która współpracuje z biblioteką Adafruit_GFX.h w ten sposób nie byłem zmuszony implementować do rozwiązania własnych czcionek. Matryca ta oprócz modułowej konstrukcji umożliwia również sterowaniem jasnością podświetlania, w tym celu aby uprzyjemnić użytkowanie w porach nocnych odbiornik został wyposażony w fotorezystor dzięki któremu potrafi określić natężenie oświetlenia otoczenia i odpowiednie ustawienie podświetlenia. Na wyświetlaczu w pierwszej kolejności wyświetlam aktualną godzinę oraz temperaturę wewnątrz pomieszczenia oraz wilgotność, po około jednej minucie wyświetlane są informacje odczytane z stacji meteo czyli temperatura wilgotność i ciśnienie, postanowiłem nie wyświetlać tutaj informacji dotyczących prędkości wiatru oraz temperatury przy gruncie. Decyzję tą podjąłem na podstawie użytkowania innego podobnego rozwiązania, akurat jak chcemy odczytać godzinę to wyświetlane są inne informacje. Dodatkowo w godzinach nocnych, które zostały ustawione w sztywnych ramach czasowych między 21:00 a 7:00 informacje odczytane z stacji meteo zostały okrojone tylko do temperatury. W projekcie zostały zastosowane 2 rodzaje animacji pierwsza z nich, przesuwa tekst z prawej strony wyświetlacza na lewą, z możliwością zatrzymania w interesujących momentach. Drugi rodzaj to pionowa animacja. Mikrokontroler również poprzez protokół NTP i bibliotekę time.h pobiera aktualną godzinę i datę. Za odbiór danych z pierwszego układu odpowiedzialny jest moduł radiowy którego obsługą tak jak w poprzednim module zajmuje się biblioteka RCswitch. Poniżej fragment programu który demonstruje w jaki sposób odbierane i dekodowane są dane: rc = mySwitch.getReceivedValue(); // czujnik temperatury powietrza BME280 if (abs(rc)>=50000&& abs(rc)<150000) { rc=(rc-100000)/100; if (rc > -50 and rc < 60) { temp1 = rc; Serial.print("Czujnik BME280 - temperatura: \t"); Serial.println(rc); matrix.drawPixel(55,0,1); matrix.write(); } } // czujnik wilgotności BME280 if (abs(rc)>=150000 && abs(rc)<250000) { rc=(rc-200000)/100; if (rc > 5 and rc <= 100) { hum = rc; Serial.print("Czujnik BME280 - wilgotnowsc: \t"); Serial.println(rc); matrix.drawPixel(55,1,1); matrix.write(); } } Dzięki zastosowaniu zewnętrznej anteny oraz odbiornika opartego na superheterodynie, zasięg w otwartym terenie to około 250 m. Po odebraniu danych z pierwszego układu poprzez moduł radiowy następuje przekazanie ich do serwera z systemem Domoticz. Domoticz to bardzo lekki system automatyki domowej, który pozwala monitorować i konfigurować różne urządzenia, przełączniki, czujniki takie jak temperatura, opady deszczu, wiatr, promieniowanie ultrafioletowe (UV), zużycie energii elektrycznej, zużycie gazu, zużycie wody i wiele więcej. Wykresy dostępne są również na stronie www http://meteo.palowice.net Poniżej film z działania odbiornika, smużenie animacji które występuje na filmiku ludzie oko nie rejestruje. Gdyby kogoś interesował kod to również zamieszczam: meteo.zip
  5. 6 punktów
    Jakiś czas temu na portalu z ogłoszeniami natknąłem się na ofertę sprzedaży zabytkowego układu scalonego AY-3-8500. Jest to dość specyficzny element, wykorzystywany na przełomie lat siedemdziesiątych i osiemdziesiątych do budowy konsol do gier pierwszej generacji. Układ scalony zawiera w swojej strukturze kompletną logikę, niezbędną do generowania kilku prostych gier, m.in. kultowego "Ponga". Wykorzystywany był m.in. w kultowym ELWRO/Ameprod TVG-10 - jedynej polskiej konsoli do gier, jaka trafiła do masowej sprzedaży. Oczywiście nie byłbym sobą, gdybym go wtedy nie kupił i nie spróbował odpalić. Zacząłem więc szukać w Sieci informacji na temat tego układu. Efekty tych poszukiwań przeszły moje oczekiwania - natknąłem się na stronę, której autor zajął się podobnym projektem. Była tam cała niezbędna dokumentacja, karty katalogowe, a także projekt płytki drukowanej konsoli wykorzystującej posiadany przeze mnie układ scalony. No cóż... Postanowiłem nie wyważać otwartych drzwi i wykorzystałem ten wzór, prowadzając jednakże pewne modyfikacje w swojej implementacji tego projektu. Największa z nich dotyczyła kontrolerów , które zbudowałem w oparciu o niewielkie, plastikowe obudowy. Musze przyznać, że tworzą one całkiem poręczne "pady". Każdy z kontrolerów jest wyposażony w potencjometr służący do kontrolowania położenia paletki oraz przycisk do serwowania. Sama konsola została umieszczona w typowej plastikowej skrzynce. Na przednim panelu znajdują się przełączniki dźwigniowe dwu i trzypozycyjne służące do konfiguracji trybu rozgrywki, a także przełącznik obrotowy, do wyboru właściwej gry. Układ AY-3-8500 pozwala na korzystanie z pistoletu świetlnego. Dwie z generowanych przez niego gier wymagają posiadania takiego sterownika. Zdecydowałem się jednak zrezygnować z jego budowy. Na płytce są wyprowadzone odpowiednie piny, więc w przyszłości będzie możliwa taka rozbudowa. Niestety strona na której znalazłem oryginalny projekt niedługo później przestała działać, jednak wciąż można się do niej dostać przez Wayback Machine. Konsola przez jakiś czas była dostępna na wystawie "Game start/game over" w krakowskim Muzeum Inżynierii Miejskiej. Przetrwała - grupy gimnazjalistów nie były w stanie jej zniszczyć. W ramach ciekawostki mogę dodać, że mojemu sześcioletniemu siostrzeńcowi spodobała się ta gra sprzed kilku dekad.
  6. 5 punktów
    Ta cewka to spędza mi sen z głowy . To jeden z dwóch tzw. aktuatorów magnetycznych, czyli mówiąc po naszemu takie serwo, w wersji minimalistycznej. Ponieważ gotowe takie cewki kosztują dosyć dużo w specjalistycznych sklepach modelarskich to postanowiłem nawijać sobie sam takie cewki z drutu 0,05mm. Powstało więc do tego celu całe ustrojstwo w postaci nawijarki bo ręcznie nie byłoby to zbyt proste. Pierwsze cewki nawijałem "na oko" i powstawały o zbyt dużej rezystancji (około 240Ω). Musiałem więc kontrolować ilość zwoi, aby celować w określoną rezystancję (docelowo około 60Ω co równa się w przybliżeniu 480 zwojom na mojej rolce). Zasilanie samolotu na bogato , malutki akumulatorek 1s i pojemność około 100-120mAh. Wracając do cewki, zasilając ją sygnałem PWM z mostka H można sterować wychyleniem magnesu 3x1mm z doklejonym ramieniem (widoczne na zdjęciach). To ramie wklejone będzie w usterzenie pionowe i poziome samolotu na ogonie. Na chwilę obecną brak ogona, bo pierwszy został przeze mnie zrecyklingowany gdyż niestety cewki przez swoją rezystancję były za słabe . PS. Podziękowania dla znajomego, który cierpliwie mi drukuje elementy 3D do tej nawijarki (i nie tylko).
  7. 5 punktów
    Witajcie. Mam do zaprezentowania mój nowy projekt. Zdalnie sterowany robot kroczący z odbiornikiem podczerwieni. Jednostką centralną jest mikrokontroler ATmega8A-PU. Robot porusza się dzięki trzem serwomechanizmom TowerPro SG90. Inspiracją do sposobu chodzenia był robot kroczący Pololu. Robot posiada 6 niebieskich diod. Ich katody są połączone z odpowiednimi pinami mikrokontrolera, dzięki czemu steruję nimi w zależności od wykonywanego ruchu robota. Anody są połączone przez rezystor z nogami robota, te natomiast są połączone z potencjałem dodatnim zasilania. Jako pilota używam telefonu z androidem wraz z aplikacją RCoid. Korzystam ze standardu RC5. Kierunkami poruszania się robota są przód, tył, obracanie w lewo i prawo. Do zatrzymania robota służy dowolna inna komenda. Sterowanie serwomechanizmów odbywa się dzięki programowo stworzonemu PWM na 8 bitowym timerze mikrokontrolera. Tak wygląda kod przerwania od przepełnienia timera: ISR(TIMER0_OVF_vect) { static uint16_t cnt; if(cnt>=r) PORTC &= ~(1<<PC3); else PORTC |= (1<<PC3); if(cnt>=m) PORTC &= ~(1<<PC4); else PORTC |= (1<<PC4); if(cnt>=l) PORTC &= ~(1<<PC5); else PORTC |= (1<<PC5); cnt++; if(cnt>625) cnt = 0; } Zmienne r m i l odpowiadają za położenie poszczególnych nóg zmieniane w pętli głównej programu. Ich zakres mieści się od 17-76 (0.5ms-2.5ms) (0°-180°). Oczywiście zakres pracy jest mniejszy. Dla przykładu dobranymi wartościami dla nogi środkowej są 42 przy oparciu na lewej części, 44 pozycja środkowa, 46 oparcie na prawej części nogi. Zmienna licznika cnt jest porównywana z wartością 625, dzięki czemu uzyskuję częstotliwość 50Hz (8000000Hz/1/256/625=50Hz [20ms] [prescaler=1]). Jeżeli chodzi o kwestie zasilania to zdecydowałem się na użycie czterech zwykłych baterii AAA dających na wyjściu ~6V co zmusiło mnie do użycia przetwornicy Pololu S7V7F5 do zasilania mikrokontrolera. Diody i serwomechanizmy są zasilane bezpośrednio z baterii. Nogi zostały wygięte ze stalowego drutu o średnicy 1.5mm. Do orczyków zostały przymocowane za pomocą stalowego drutu o średnicy 0.3mm. Koniec każdej nogi zalałem gorącym klejem tak, aby zapobiec ślizganiu się robota na gładkiej powierzchni. Lista elementów: mikrokontroler ATmega8A-PU 3x serwomechanizmy TowerPro SG90 przetwornica Pololu S7V7F5 odbiornik podczerwieni TSOP31236 6x diody niebieskie rezonator kwarcowy 8MHz trytki i rurki termokurczliwe druty stalowe o średnicy 1.5mm, oraz 0.3mm płytka stykowa 170 otworów 4x baterie AAA z koszykiem parę rezystorów, kondensatorów i przewodów Zapraszam do śmiałego pisania swoich pytań, opinii i uwag Pozdrawiam, Karol
  8. 5 punktów
    LiPol Charger v1.0 / v2.0 Szanowni czytelnicy forum w tym krótkim artykule przedstawię Wam projekt ładowarki do akumulatorów litowo-polimerowych 2 celowych (7,4V). Prace nad projektem rozpoczęły się bardzo dawno temu, co można było śledzić w tym wątku. Dużą rolę w trakcie projektowania samego układu odegrał kolega @marek1707. Tak naprawdę ostateczna forma pierwszej wersji ładowarki została bardzo mocno zasugerowana przez niego dzięki temu działa ona niezawodnie. Układy zostały zaprojektowane wedle następujących założeń: możliwość ładowania akumulatorów 2 celowych przy pomocy źródła zasilania o napięciu 5V i natężeniu prądu nie większym niż 1A (na tyle pozwalały zastosowane elementy elektroniczne) oraz ładowanie z wykorzystaniem 2 paneli słonecznych 6V/300mA, które aktualnie miałem pod ręką - stąd zastosowano układ przetwornicy typu boost, zastosowanie przewodowej lub bezprzewodowej komunikacji z komputerem PC, wykorzystanie diod LED do sygnalizacji stanów pracy ładowarki, (v2.0) wyświetlanie informacji na wyświetlaczu alfanumerycznym 2x16, (v2.0) dodanie przycisków do ręcznej interakcji użytkownika z urządzeniem, (v2.0) wbudowanie prototypu prostego balansera ogniw, (v2.0) wyprowadzenie padów do programowej kalibracji przetwornika ADC. LiPol charger v1.0 Wersja pierwsza ładowarki jest wersją niekombinowaną oraz dość niezawodną. Pełny cykl ładowania akumulatora obejmuje zarówno fazę CC (stałoprądową) oraz CV (stałonapięciową). Cykl ten świetnie obrazuje WYKRES, który podrzucił mi kolega @marek1707 i który zapamiętam do końca swojego życia Zasadę działania przetwornicy boost wydaje mi się, że każdy elektronik powinien znać. Jeśli jednak czytelniku nie miałeś okazji zapoznać się z tym rodzajem przetwornic podsyłam ciekawe artykuły na ten temat: LINK, LINK. W skrócie - na wejściu przetwornica otrzymuje napięcie maksymalne 6V oraz prąd maksymalny 1A. Sygnał PWM generowany przez mikrokontroler ze stałą częstotliwością, a zmiennym wypełnieniem otwiera lub zamyka tranzystor kluczujący przetwornicę, który dzięki temu reguluje napięcie lub prąd wyjściowy przetwornicy w zależności od fazy algorytmu ładowania CC/CV. Zastosowano w tym celu najzwyklejszy regulator proporcjonalny. Mikrokontroler ma możliwość pomiaru potrzebnych parametrów tj. napięcia i prądy wejściowe/wyjściowe oraz napięcie międzyogniwowe. Napięcia są mierzone poprzez dzielniki napięciowe natomiast pomiar prądów odbywa się z wykorzystaniem układów bocznikowych. Komunikacja z komputerem odbywa się poprzez moduł Bluetooth (BTM222 lub HC-05) lub z wykorzystaniem przejściówki USB-UART. Dodatkowo domowymi metodami wykonałem shield umożliwiający podłączenie wyświetlacza alfanumerycznego 2x16. Ostatecznie wykorzystując źródło napięcia stałego 5V/1A udało się uzyskać przetwornicę o sprawności ok. 65%. Całkiem niezły wynik jak na prototyp. Straty mocy są związane ze stratami na diodzie, indukcyjności oraz NIE zastosowaniu kondensatorów typu Low ESR. Wszystkie te parametry można jeszcze trochę poprawić przez co możliwe jest zwiększenie sprawności samej przetwornicy. Wykorzystanie do ładowania paneli słonecznych zmusiło do zastosowania najprostszego algorytmu MPPT - śledzenia punktu maksymalnej mocy. Panele słoneczne połączone są równolegle przez co uzyskano większy prąd wejściowy na przetwornicę. W tym połączeniu maksymalny prąd wejściowy wynosi 600 mA dla posiadanych przeze mnie paneli 6V/300mA. Biorąc pod uwagę to, że w polskich warunkach z tych paneli jestem w stanie wyciągnąć maksymalnie 70-80% całkowitej sprawności przy bezchmurnej pogodzie prąd ładowania akumulatorów jest niewielki. Dlatego ten tryb ładowania sprawdza się raczej przy niewielkich akumulatorach. Ale najważniejsze, że się sprawdza LiPol charger v2.0 Druga wersja ładowarki nie została jeszcze przetestowana!!! Natomiast wzbogaciłem ją o kilka praktycznych dodatków, których brakowało mi w poprzedniej wersji. Wersja v2.0 została wzbogacona o prototyp balansera złożonego z dwóch oporników dużej mocy oraz tranzystorów sterowanych z poziomu mikrokontrolera, który na podstawie pomiaru napięcia międzyogniwowego decyduje o tym, który obwód „strat mocy” załączyć. Jeśli któryś z tranzystorów zostaje otwarty, przez rezystor przepływa prąd, natomiast ładowanie danego ogniwa akumulatora jest pomijane. Dzięki temu możliwe jest wyrównanie poziomów napięć na obu ogniwach. Dodatkowo wyprowadzone zostały pady pomiarowe, które znacznie ułatwiają kalibrację odczytów z przetwornika ADC. Wbudowano również konwerter USB-UART na podstawie chipu FT230XQ, wyprowadzono również piny Rx i Tx w celu podłączenia np. modułu Bluetooth. W tym projekcie udało się znacząco zmniejszyć wymiary ładowarki. Kompletne schematy obu wersji ładowarki udostępniam w pdf’ach poniżej. LiPolCharger_v1_0.pdf LiPolCharger_v2_0.pdf Wykaz ważniejszych elementów wykorzystanych w układach ładowarek: mikrokontroler ATmega32 tranzystor kluczujący MOSFET-N STS12NF30L driver MOSFET MCP1402T cewka 220 uH wzmacniacze operacyjne LM358 wyświetlacz alfanumeryczny 2x16 konwerter USB-UART FT230XQ, tranzystory bipolarne NPN i PNP dowolne, pod warunkiem, że maksymalny prąd kolektor-emiter będzie większy niż 1A. Jeśli ktoś z czytelników będzie zainteresowany tematem owych ładowarek serdecznie zapraszam do zadawania pytań w komentarzach, a także ewentualnego krytykowania (oczywiście konstruktywnego) mojego projektu.
  9. 5 punktów
    Pojawiła się potrzeba wykonania prostego sterownika do bramy garażowej, który miałby powiadamiać mieszkańców czy aktualnie garaż jest zamknięty czy otwarty oraz w dowolnej chwili sprawdzić status. Tak powstało niewielkie urządzenie montowane na szynę DIN. Jest zasilane z dowolnej ładowarki od telefonu, posiada zabezpieczenie przed odwrotną polaryzacja zasilania. Sterownik ma kilka wejść/wyjść; IN1 - dolna krańcówka od zamknięcia garażu. IN2 - górna krańcówka od pełnego otwarcia garażu. wyjście przekaźnikowe NO do zdalnego otwierania/zamykania bramy. RS485 - pozwala podłączyć czujnik odległości wykrywający czy auto jest w garażu. czujnik temperatury DS18B20. przycisk do resetowania ustawień WiFi i uruchomienia ponownej konfiguracji. W sterowniku zastosowałem popularny układ ESP8266 w wersji WemosD1 mini. Jak widać za wiele rzeczy tu nie ma, oprócz ESP znajduje się przekaźnik, DS18B20 oraz transceiver RS485. Projekt miał być prosty, szybki i jednostkowy dlatego nie zastosowałem dodatkowych stopni ochrony wejść w postaci np. optoizolacji. Tradycyjnie płytka powstała na żelazku i wytrawiona w kwasie. Polutowana i zabezpieczona lakierem do PCB. Schemat ideowy: Wspomniany wcześniej czujnik odległości jest zbudowany z wykorzystaniem ultradźwiękowego czujnika HC-SR04 i Arduino Nano, które cyklicznie wysyła informacje do głównego sterownika. Schemat czujnika: Sterownik ma zaimplementowany serwer WWW co pozwala na sterowanie praktycznie dowolnym urządzeniem z przeglądarką. A panel sterowania prezentuje się tak: Dodałem obsługę powiadomień push na telefon z wykorzystaniem mechanizmu IFTTT (if this then that). Wystarczy zainstalować tą aplikacje na telefonie, a w sterowniku wprowadzić unikalny klucz aplikacji powiązany z konkretnym telefonem. Aktualizacja oprogramowanie wykorzystuje mechanizm OTA i sprowadza się do wgrania pliku przez panel www. Dodatkowo wystawione jest proste API, które pozwala na integracje z większością systemów smart home typu Domoticz, Home Assistant itp.
  10. 5 punktów
    Cześć, Jestem z Koła Naukowego Robotyków z Politechniki Warszawskiej. Niedawno stwierdziliśmy, że w sumie fajnie by było opisać gdzieś nasze konstrukcje. Jako, że zdarza nam się korzystać z zasilaczy z czarnej listy, padło na forbota . Na pierwszy ogień chcieliśmy wypuścić jedną ze starszych maszyn – Minotaura. Jego historia była dość ciekawa – na 3 tygodnie przed ubiegłorocznymi zawodami Robomaticon razem z kolegą stwierdziliśmy, że może fajnie byłoby wystawić tam jakiegoś Micromouse’a. Postawiliśmy zatem na jak najprostsze rozwiązania, które z jednej strony pozwoliłyby nam przetestować różne algorytmy jazdy, z drugiej zaś zaoszczędziłyby czasu na wykonanie oraz programowanie. Dzięki temu jednak konstrukcja jest dość prosta i może być dobrym projektem dla początkujących robotyków. Mechanika Bazę montażową dla całego robota stanowi obudowa wydrukowana na drukarce 3D. Pierwsza wersja zakładała, że podstawa robota będzie rozpostarta na kwadracie o długości 110 mm o zaokrąglonych narożach. Po wykonaniu prototypu oraz pierwszych testach bardzo szybko okazało się jednak, że robot jest zdecydowanie za duży. Z uwagi na to, że możliwe okazało się zmniejszenie odległości pomiędzy silnikami bez uszczerbku na działaniu enkoderów magnetycznych, zdecydowano się znacznie ograniczyć wymiary robota. Kolejna (ostateczna) wersja robota miała już w podstawie kwadrat o boku 80 mm. Aby móc ograniczyć wymiary, zdecydowano się na węższe ścianki boczne. Z uwagi na dużą łamliwość, zrezygnowano z drukowanych mocowań do płytek z elektroniką i zastąpiono je gotowymi, plastikowymi dystansami. Ostateczny wynik można oglądać na zdjęciu poniżej: W robocie Minotaur zdecydowano się na zastosowanie silników POLOLU z metalową mikroprzekładnią 50:1 z obustronnym wałem. Pozwoliło to na zastosowanie enkoderów magnetycznych tej samej firmy. Na wałach silników zamocowano wykonane metodą druku 3D koła. W pierwszej wersji zastosowano opony odlewane z silikonu, jednak później (ze względu na dość szybkie zużywanie się silikonowych) zdecydowano się na wykorzystanie opon Kyosho Mini-Z. Pozwoliło to zminimalizować poślizgi. Dodatkowymi elementami są elementy podporowe, oklejone taśmą teflonową oraz górna pokrywa robota, do której jest mocowana bateria. Elektronika Ze względu na małe zasoby czasowe oraz dostępność części w laboratorium elektronika robota Minotaur została oparta na Arduino Uno. Prawie cała pozostała elektronika (z wyjątkiem sensorów) została umiejscowiona na shieldzie wpinanym w Arduino. Poza wspomnianymi wcześniej silnikami z enkoderami, zastosowano jedynie kilka komponentów. mostki TB6612FNG, które (ze względu na przykre doświadczenia w poprzednich konstrukcjach) zastosowano po jednym dla każdego silnika (zwarto wyprowadzenia). Za interfejs użytkownika służyły 1 przycisk oraz 1 dioda. Poza tym za pomocą dzielnika napięcia monitorowano stan baterii. Aby poprawić jazdę, zdecydowano się na zastosowanie czujnika IMU (Pololu Mini-IMU 9), który znaleźliśmy w laboratorium. Jednak, nawet przy wyłączonym żyroskopie robot radził sobie w labiryncie. Wypinany moduł Bluetooth służył głównie do doboru nastaw podczas programowania (obecnie nie jest on wykorzystywany). W robotach zastosowano czujniki odległości stworzone z 2 diód IR oraz fototranzystora. Światło emitowane przez diodę IR odbija się od ściany labiryntu i wraca do fototranzystora. Zastosowano jedynie 3 takie czujniki, umiejscowione na środku ścian robota. Jeden z nich ma za zadanie sprawdzać, czy ściana jest na wprost. Pozostałe 2 umiejscowione na bokach sprawdzają, czy ścianka istnieje z boku. Pozwalają także robotowi utrzymać stałą odległość pomiędzy ściankami. Innym ich wykorzystaniem jest snapowanie – jeżeli robot ma mały błąd kątowy (liczony na bieżąco), to w momencie gdy jakaś ścianka mu się kończy, aktualizuje swoje położenie. Algorytm Podobnie jak w większości konstrukcji, które nie poruszają się metodą prawej/lewej dłoni, w robocie został zaimplementowany algorytm „flood fill” - zalewania wodą (Bellmana - Forda). Naszą jedyną modyfikacją, była preferencja jazdy prosto (obrót jest dla nas bardziej kosztowny). Aby nie zmuszać bardziej zaawansowanych czytelników do przewijania, początkujących odsyłam do linku: [LINK] Aby móc choć nieco przystosować się do warunków zmiennego oświetlenia, na początku każdego przejazdu dokonujemy kalibracji. Aby robot mógł swobodnie poruszać się po labiryncie powinien on potrafić wykonywać 2 podstawowe ruchy: jazda do przodu oraz skręt (o 90o w prawo i lewo, obrót o 180o). Przed jazdą powinien on jednak skalibrować czujniki. Do obrotu wykorzystywane są dwa czujniki: enkodery oraz żyroskop. Wiodącym czujnikiem jest żyroskop, z którego po scałkowaniu prędkości otrzymujemy kąt obrotu. Enkodery wykorzystywane są głównie do kontroli prędkości obrotowej kół, aby robot obracał się w miejscu bez zbędnego przemieszczenia (jeśli oba koła kręcą się z ta samą szybkością wówczas robot obraca się wokół swojego środka). Aby zminimalizować szanse kolizji robota ze ścianami labiryntu podczas jazdy wykorzystuje się odczyty z trzech typów czujników: odległości, enkoderów oraz żyroskopu. Każda z tych wartości jest uwzględniana z odpowiednią wagą, która została dobrana w sposób eksperymentalny. Wagi nie są jednak stałe, ale zależne od ułożenia ścianek lub ich braku. Do utrzymywania kierunku wykorzystywane są enkodery oraz żyroskop, natomiast czujniki odległości służą do utrzymywania robota w równych odstępach od bocznych ścianek niwelując niedokładności obrotów. Do jazdy na wprost podobnie jak podczas obrotu wykorzystywany jest regulator PD. Innym ważnym aspektem jest pokonywanie zadanego dystansu, jest to długość pojedynczej komórki. Błędy podczas pomiaru odległości mogą skutkować złym zmapowaniem labiryntu bądź kolizją ze ścianką. Korzystając z faktu, że kształt labiryntu jest znormalizowany możemy bazować robota do punktów charakterystycznych (w tym wypadku jest to początek bądź koniec ścianki). Korzystając z bazowania co pewien czas zerowany jest błąd położenia (np. w miejscach pokazanych na rys. poniżej). I na koniec coś co wszyscy lubią najbardziej, czyli robot w akcji. Niestety nie jest to najnowsze wideo, ale na pewno w najlepszej jakości, czyli przejazd robota podczas zawodów ISTROBOT w Bratysławie.
  11. 4 punkty
    Manipulator "Copernicus" to mój najnowszy projekt, model 4-osiowego robota przemysłowego z ssawką podciśnieniową jako efektorem. Bezpośrednim przyczyną rozpoczęcia budowy był zachwyt nad tego typu profesjonalnymi konstrukcjami, typu Kuka, ABB, Fanuc itd., a które można podziwiać między innymi na różnych targach przemysłowych Robot powstawał w ekspresowym jak dla mnie tempie, około 2 miesięcy, a jego budowa nie byłaby możliwa bez wsparcia sponsorów, którym chciałbym w tym miejscu serdecznie podziękować: Agencji Pracy MONDI Polska, która w ramach programu stypendialnego Mondi Wspiera Talenty sfinansowała większość niezbędnych elementów i części; Firmie IGUS Polska, która jako próbkę udostępniła mi przekładnię ślimakową RL-D-30; Firmie STMicroelectronics, dzięki której otrzymałem płytkę Nucleo; Zespołowi Szkół Łączności im. M. Kopernika w Poznaniu, również za pomoc finansowo-merytoryczną. Dobrze, na początek kilka zdjęć ogólnie przedstawiających robota - przepraszam za nienajlepsze tło, zdecydowanie lepiej ideę pracy robota wyjaśniają filmy Konstrukcja jest trójmodułowa, pierwsze cztery zdjęcia ilustrują właściwego robota, piąte przedstawia stację generującą podciśnienie, dwa ostatnie to sterownik robota Mechanika Podstawę robota stanowi prostokąt plexiglass'u 10mm. Pierwsza oś swobody jest pryzmatyczna, składa się z dwóch prowadnic liniowych ø10 i listwy zębatej. Następnie, na wózku z łożyskami liniowymi DryLin, również firmy Igus, znajduje się pierwsza oś obrotowa z wspomnianą już przekładnią ślimakową. Następnie, trzecią oś swobody, a drugą obrotową stanowi silnik z przekładnią planetarną oraz paskiem zębatym HTD. Ostatnią, czwartą oś, służąca ustawieniu ssawki prostopadle do powierzchni, stanowi ssawka podciśnieniowa Festo, bezpośrednio obracana przez silnik krokowy NEMA17. Taki sam silnik napędza przekładnię ślimakową, natomiast w pierwszej i trzeciej osi wykorzystałem, jak wspomniałem, silniki z wbudowaną przekładnią planetarną. Elektronika Sterownik robota jest trójpoziomowy - na pierwszym z nich znajduje się gniazdo trapezowe, sygnalizatory napięć i 2 zasilacze - 24V/8,5A oraz 12V/5A. Ten pierwszy zasila tylko silniki, natomiast drugi - pompkę podciśnieniową, elektrozawór i wszystkie pozostałe elementy, wykorzystując w tym celu przetwornicę step-down (dającą na wyjściu 5V DC - Nucleo wykorzystuje własny, znajdujący się na płytce stabilizator 3,3V). Na drugim poziomie znajdziemy wspomniane Nucleo F103 i przetwornicę, 2 przekaźniki do sterowania pompką i elektrozaworem, płytkę dystrybuującą zasilanie oraz 4 sterowniki silników krokowych TB6560. Na trzecim poziomie - przycisk bezpieczeństwa i 2 wentylatory. Płyty w sterowniku wykonane są również z plexi 5mm. Do połączeń sterownik-robot-stacja generująca podciśnienie używam w większości złącz wielopinowych dedykowanych automatyce. Robot posiada czujniki krańcowe, potrafi się zerować. Oprogramowanie Napisałem program w Arduino IDE, który zawiera kinetykę odwrotną liczoną z zależności geometrycznych oraz korzystając z biblioteki AccelStepper() steruje "na sztywno" wszystkimi czterema silnikami krokowymi. Następnie wpisałem kilkanaście punktów, i tak robot układa krążki i rozkłada, i tak w pętli... Osiągnięcia, dalsze plany i film Aktualnie, robot może pochwalić się wzięciem udziału w RoboDay 2019 (pokazy na Politechnice Poznańskiej) i II miejscem na µBot (zawody organizowane przez V LO Kraków). Projekt jest aktualnie zamknięty, ale myślę nad rozwojem konstrukcji, na przykład dodaniem kamery PixyCam2. Opis jest dość zwięzły - gdybyście mieli jakiekolwiek pytania, chętnie dopowiem szczegóły Pozdrawiam, wn2001
  12. 4 punkty
    Ze względu na cenę, prostotę, wystarczającą do latania jakość i małe opóźnienia systemy FPV posługują się pradawnym standardem telewizji analogowej PAL. Dlatego na wyjściu takiego odbiornika dostajesz sygnał tzw. composite video po jednym drucie i to wprowadzasz do monitora, którym może być zwykły telewizor z odpowiednim wejściem, gogle itp. Jeśli chcesz taki sygnał wciagnąć do komputera (niechby i do Maliny) potrzebujesz tzw. frame grabbera czyli urządzenia, które "rozumie" analogowy sygnał CVSB, "rozpakowuje go" na kolejne ramki obrazu, ew. kompresuje i udostępnia w postaci cyfrowej np. przez USB. Poszukaj hasła "usb frame grabber" lub np. "usb video capture" - powinno pomóc. EDIT: Pierwszy z brzegu: https://rc-planeta.pl/pl/okablowanie-i-akcesoria/666-konwerter-fpv-usb-grabber-konwerter-video.html ale jest tego pełno.Szukaj w sklepach modelarskich albo RTV/AGD w działach video lub na aukcjach.
  13. 4 punkty
    RozZuBeN – Robot z Zupełnie Bezsensowną Nazwą Jest to robot klasy nanosumo, który został stworzony na wiosnę 2018 roku przez Pojemnika i mnie - wtedy uczniów pierwszej klasy VIII LO w Poznaniu. Zainteresowaliśmy się tą kategorią na Robomaticonie 2018, gdzie nie było żadnego sumo w tej skali. Pomyśleliśmy, że gdybyśmy mieli akumulator z silnikiem, to byśmy łatwo zgarnęli nagrodę za ostatnie (pierwsze!) miejsce. Tak powstał ten robot. Przestudiowaliśmy regulaminy różnych zawodów i wyodrębniliśmy minimalne założenia które musi spełniać nasz robot podczas zawodów: Poruszanie się Nieporuszanie się (przed startem) Po starcie nie może się zatrzymać na dłużej niż 30 sekund Czekanie 5 sekund po starcie Fajnie by było, gdyby sam z siebie nie wypadał z ringu Udało nam się spełnić wszystkie 5 punktów. Płytka: O ile 1, 2 i 3 punkt założeń projektowych można rozwiązać jednym przełącznikiem, to do czwartego potrzebne by było jakieś opóźnienie (układ RC lub popularny NE555 z tranzystorem). 5 punkt przekonał nas do użycia mikrokontolera. Zastosowaliśmy attiny84, które ilością pinów cyfrowych zapewniło nam dużą elastyczność w projektowaniu płytki. Taktowany jest wewnętrznym oscylatorem (miał być zewnętrzny generator kwarcowy ale nie mogliśmy go polutować). Umieściliśmy sterownik silników A3901 z którego wykorzystujemy tylko jeden z dwóch kanałów, dwa czujniki KTIR0711s jako czujniki krawędzi ringu podłączone bezpośrednio do ADC mikrokontrolera, dwa ledy sygnalizacyjne (zielony i bursztynowy, który jest w praktyce pomarańczowy ), przełącznik do startowania robota, dzielnik rezystorowy do mierzenia napięcia akumulatora (chyba nawet niewykorzystany), złącze do programowania (2x3 żeńskie goldpiny precyzyjne) i stabilizator napięcia na 3,3V w obudowie SOT23 (nie pamiętamy oznaczenia). W Eaglu zrobiliśmy kwadrat 25x25mm, rozmieściliśmy elementy „na oko”, połączyliśmy ścieżkami, i wysłaliśmy do OSH Parku. Zajęło nam to dwie godziny. Był to koniec marca, płytka przyszła w połowie maja. Wcześniej zamówiliśmy wszystkie elementy, ale oczywiście pomyliliśmy attiny84 z attiny88, więc złożenie potrwało trochę dłużej niż przewidywaliśmy. Płytkę lutowało się całkiem dobrze, choć do drobnych elementów chyba jednak lepsze są płytki cynowane zamiast złoconych (niby złoto lepiej przewodzi prąd ale cynę najlepiej się lutuje do innej cyny). Praktycznie od razu płytka dogadała się z programatorem (co nie było takie oczywiste w naszych poprzednich robotach). Konstrukcja mechaniczna: Mieliśmy kilka pomysłów na spełnienie pierwszego założenia projektu: silniczek wibracyjny z jakiegoś telefonu, żeby robot tylko drgał (przecież ruch to ruch) albo umieszczenie dwóch silników tak by stykały się wałami z podłożem, aby nie była potrzebna przekładnia, mechanizmy sprężynowe chyba też były... Porządna przekładnia z zębatek odpadała, bo nie wiedzieliśmy jak ją zrobić. Ostatecznie wykorzystaliśmy przekładnię cierną. Wał silnika z nałożoną rurką termokurczliwą (dla lepszego tarcia) jest przyciśnięty do opony jedynego w robocie kółka wyciągniętego z jakiejś zabawki. Brzmi to okropnie i tak też zostało to zmontowane. „Felga” kółka trze o korpus silnika, więc to miejsce musi być często smarowane wazeliną techniczną, żeby robot nie zaciął się podczas walki. Wszystko jest zalane gorącym klejem z drucikami z goldpinów tworzącymi swego rodzaju usztywnienie. Czasem gorący klej sprawiał problemy czujnikom przeciwników (nie wiemy dlaczego). Robot o jednym kółku nie przewraca się, ponieważ na całej podstawie ma przyklejony kawałek styropianowej tektury znaleziony w szufladzie. Przed i za kołem znalazło się też trochę miejsca na ktiry. Wszystko połączyliśmy kabelkami, przykleiliśmy akumulator (Li-Po 1S 150 mAh) (oczywiście też na gorący klej) i włączyliśmy. Okazało się, że silnik jest za mocny i wywraca robota tuż po starcie, ale i tak byliśmy dumni, że robot porusza się całkiem skutecznie. Zrezygnowaliśmy też z przełącznika, który był bardzo niewygodny i zastąpiliśmy go odbiornikiem IR. Nie chcieliśmy się bawić z dekodowaniem sygnałów, więc sygnał połączyliśmy dużym kondensatorem do masy zmieniającym dane na jedną dłuuugą jedynkę odczytywaną przez procesor. Program: Po wielu próbach doszliśmy do wniosku, że najlepiej jest poruszać się metodą krótkich „skoków” polegających na szybkim włączeniu i wyłączeniu silnika (wtedy robot nigdy się nie przewracał). Po każdym „skoku” robot sprawdza czy jest na krawędzi. Jeśli tak to zaczyna poruszać się w drugą stronę i zapala bursztynowego leda. Po 10 sekundach ruchu robot zatrzymuje się na równe 10 sekund aby to przeciwnik zużywał akumulator. Całość powtarzana jest aż do utraty zasilania. Ta technika działa zaskakująco dobrze w przypadku konfrontacji z robotem, który też jest „ślepy”. Podczas ruchu może niechcący wypchnąć przeciwnika, a kiedy stoi bardzo ciężko jest go ruszyć (chyba, że przeciwnik jest rozpędzony lub ma dobre silniki). Akumulator starcza na bardzo dużo często remisowych walk. Zwykle ładujemy go przed zawodami do 4,20V a po walkach nadal ma ponad 4,10V. Osiągnięcia: 2018: 3. miejsce Bałtyckie Bitwy Robotów 3. miejsce Robocomp 2. miejsce Sumo Challenge 2019: 4. miejsce Robotic Arena 1. miejsce Robomaticon Robot tylko na Robotic Arena zajął ostatnie miejsce. Na każdych zawodach miał 3 przeciwników, więc na Robomaticonie wygrał ze wszystkimi! (z czego z jednym walkowerem) Wnioski: Robot spisuje się niespodziewanie dobrze, co obrazuje niestety poziom konkurencji w Polsce. Aktualnie kończymy prace nad kolejną konstrukcją, która tym razem będzie miała dwa kółka i będzie widzieć przeciwnika, co pozwoli liczyć na walkę a nie tylko łut szczęścia. Mamy nadzieję, że aktywnie zawalczy o pierwsze miejsca. Kilka filmów z zawodów: Chętnie odpowiemy na wszystkie pytania dotyczące robota.
  14. 4 punkty
    Cześć, od kiedy opisałem swojego robota Pika na forum, minęło już troszkę. W tym czasie zdążyło powstać kilka kolejnych konstrukcji, zarówno bez turbiny jak i z turbiną. W tym poście chciałbym przybliżyć Wam moją najnowszą konstrukcję - robota klasy Linefollower Turbo o nazwie Spark. Głównym założeniem, jakie przyświecało mi podczas projektowania była chęć nauczenia się wektorowego sterowania silnikami BLDC oraz wykorzystanie właśnie takich silników jako napęd bezpośredni w robocie. Podczas opisu założeń konstrukcyjnych posłużę się modelem 3D robota. Jak można zauważyć na powyższym zdjęciu, ogólna konstrukcja nie różni się od znanego wszystkim standardu. Na przedzie delikatna i lekka listewka z 14 czujnikami linii KTIR0711S. Centralnie umieszczona turbina QX-Motor 14000 kv o średnicy 30 mm. Dwa silniki hexTronik 1300KV umieszczone w tylnej części w taki sposób, aby możliwe było uniesienie przodu celem wjazdu na pochylnię/rampę w kategorii Linefollower Enchanced. Sercem robota jest mikrokontroler STM32H743VIT6. Jest on oparty na rdzeniu Cortex M7 oraz taktowany z prędkością 400 MHz. Wybór tak potężnej jednostki sterującej podyktowany był chęcią wydajnego obliczania komutacji sterowania wektorowego dla każdego z silników jezdnych oraz realizacji algorytmu jazdy przy pomocy tylko jednej jednostki. Dodatkowo tak szybki mikrokontroler pozwolił na zatuszowanie moich niedoskonałości w optymalizacji kodu Głównym elementem konstrukcyjnym jest 4-warstwowy obwód drukowany. W trakcie projektowania falowników do sterowania silnikami powstały dwa prototypy, w których miałem problem z przegrzewającymi się tranzystorami dlatego w docelowym PCB zastosowałem aż 4 warstwy. Dodatkową zaletą takiego obwodu jest jego większa odporność na zakłócenia elektromagnetyczne. Podświetlony obszar to miedź na wszystkich czterech warstwach połączonych setkami przelotek chłodząca tranzystory. Do sterowania każdym z silników wykorzystałem 6 tranzystorów w układzie pełnego mostka 3-fazowego. Posłużyły mi do tego półmostkowe układy BSG0813NDI za których udostępnienie serdecznie dziękuję firmie Infineon (oraz za tranzystory i drivery, które spaliłem w prototypach - ok 60 sztuk, nie od razu Rzym zbudowano ) Ostatecznie jako drivery wykorzystane zostały układy MIC4607-2 ze względu na możliwość sterowania całym mostkiem przy pomocy tylko jednego układu. Do odczytywania pozycji wirnika służy enkoder magnetyczny AMS5045B. Całość zasila akumulator Li-Po Tattu 450mAh 7.4V 75C. Za komunikację bezprzewodową odpowiada stary dobry moduł HC05. W celu zapewnienia pod robotem podciśnienia wywoływanego turbiną, zwiększającego nacisk kół na podłoże obrys uszczelniony został wydrukowaną w 3D ścianą. Do usztywnienia konstrukcji tak, aby opierała się ona o podłoże tylko kołami i ślizgaczami z przodu, posłużyły wałki węglowe o średnicy 4 mm. Do połączenia ze sobą poszczególnych elementów konstrukcyjnych wykorzystane zostały aluminiowe mocowania wykonane w technologii WEDM. Poniżej kilka fotek. Prototyp 1: Ratowanie prototypu 1 (rezystory bramkowe? A na co to potrzebne ) : Prototyp 2: Elementy konstrukcyjne: Pierwsze ruchy silnika: Poszukiwanie granic: Opona wykonana z poliuretanu 20': Aluminiowa felga wciśnięta na wirnik (Pololki dla skali): Zamontowana felga wraz z oponami (Mini-Z 20'): Turbina po dezintegracji (podczas jazdy eksplodowała): Przejazd w konkurencji Linefollower Drag podczas Bałtyckich Bitw Robotów 2018: Próby podczas RobotChallenge 2018 w Pekinie: Wnioski: Konstrukcja waży 250 g. To zdecydowanie za dużo, gdyż opony nie są w stanie zapewnić wystarczającej przyczepności na zakrętach i robot wpada w poślizg na zakrętach przez co osiągnięcie prędkości średniej na krętej trasie powyżej 3 m/s jest bardzo trudne. Zastosowanie silników BLDC jako direct-drive umożliwia rozpędzenie robota do ogromnych prędkości liniowych (15 m/s+) lecz aby posiadały one zadowalający moment przy niskich obrotach konieczny do gwałtownych zwrotów muszą być duże i ciężkie. Lepiej zastosować małe silniki z przekładnią. Nowa konstrukcja już się tworzy! Dziękuję za przejrzenie albumu, który utworzyłem i zapraszam do zadawania pytań w komentarzach
  15. 4 punkty
    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ł
  16. 4 punkty
    Witam serdecznie, Chciałbym zaprezentować mój projekt którym jest czworonożny robot kroczący sterowany za pomocą kolna arduino - nano V3. Głównym celem powstania tej konstrukcji było zabicie wolnego czasu oraz wykorzystanie nowo zamówionych części. Cały proces tworzenia od koncepcji do gotowego czworonoga trwał poniżej tygodnia. Funkcjonalność robota skupiała się na chodzeniu do przodu oraz pokonywaniu małych przeszkód. Elektronika Do stworzenia projektu potrzebny był kontroler - wspomniane już wcześniej arduino nano lub jego klon. W mojej opinii jest to najbardziej użyteczne arduino do projektów DIY, ze względu na jego małą wielkość i masę oraz identyczne możliwości obliczeniowe jak jego więksi bracia. Arduino zostało zamontowane na płytce rozszerzającej z wieloma wyprowadzeniami dla serw i nie tylko. Ten element jest bardzo uniwersalny i ułatwia podłączenie wielu komponentów bez potrzeby tworzenia odpowiedniej płytki PCB lub używania płytki stykowej. Motoryka została oparta o małe serwomechanizmy - po dwa na nogę, łącznie 8 sztuk. Dodatkowo na końcach nóg zostały zamontowane czujniki krańcowe w celu wykrywania kolizji z podłożem i optymalizacji ruchu. Siła serwomechanizmów okazała się być wystarczająca, jednakże, problemem okazało się być zasilanie. Duża ilość serwomechanizmów działających jednocześnie mocno obciąża arduino, dlatego też, serwomechanizmy powinny mieć własne źródło zasilania. W tym przypadku ograniczenie prędkości ruchów ograniczyło ten problem, ale wskazuje to na popełniony przy projektowaniu błąd. Konstrukcja Konstrukcja składa się z korpusu głównego do którego przymocowano arduino oraz 4 nóg. Jedna noga składa się z dwóch segmentów, a jeden segment z dwóch elementów łączonych śrubą. Lepiej wyjaśni to poniższe zdjęcie. Robot jest tu przedstawiony leżący na swoich plecach. Poniżej znajdują się jeszcze dwa zdjęcia pokazujące jego posturę. W pozycji leżącej, ze wszystkimi nogami skierowanymi względem siebie pod kątem prostym, robot ma przekątną około 30 cm. Powyższe elementy zostały wydrukowane przy pomocy drukarki 3D. Trwało to około 10 godzin. Kod Ze względu na krótki czas rozwoju projektu, jego funkcjonalność nie jest duża. Postało kilka wersji programu, dopasowanych do konkretnego podłoża. Nie różnią się one znacząco, więc przedstawię główny program służący do pokonywania płaskiego terenu w najszybszy i najstabilniejszy sposób. Na początek trochę definicji. Zmienne nazwane są od numeru nogi oraz jej stopnia. Przykładowo tl1 - top-left-1, oraz br2 - bottom-right-2. #include <Servo.h> Servo tr1; Servo tr2; Servo tl1; Servo tl2; Servo br1; Servo br2; Servo bl1; Servo bl2; #define br A1 #define tr A2 #define tl A3 #define bl A4 int i=0; int o=50; int p=20; int h=70; int t=10; int k=0; int l=0; int n=0; int m=0; int timer=0; int d=0; int x=50; int y=50; void setup() { Serial.begin(9600); pinMode(A1, INPUT_PULLUP); pinMode(A2, INPUT_PULLUP); pinMode(A3, INPUT_PULLUP); pinMode(A4, INPUT_PULLUP); tl1.attach(8); tl2.attach(4); bl1.attach(9); bl2.attach(5); tr1.attach(10); tr2.attach(6); br1.attach(11); br2.attach(7); tr1.write(90); tr2.write(75); tl1.write(90); tl2.write(90); br1.write(90); br2.write(90); bl1.write(90); bl2.write(90); } Kolejnym elementem kodu są definicje funkcji. void ltl(int a, int b){ tl1.write(map(a+3, 0, 100, 10, 150)); tl2.write(map(b, 100, 0, 5, 180)); } void ltr(int a, int b){ tr1.write(map(a, 100, 0, 30, 170)); tr2.write(map(b-9, 0, 100, 0, 177)); } void lbl(int a, int b){ bl1.write(map(a, 0, 100, 30, 150)); bl2.write(map(b+1, 0, 100, 0, 178)); } void lbr(int a, int b){ br1.write(map(a, 100, 0, 30, 150)); br2.write(map(b+4, 100, 0, 8, 180)); } void move(){ lbr(100-i,100-k-d); i++; if(i==100){ i=0; k=y; } if(k>0){ if(digitalRead(br)==HIGH){ k--; } } lbl(100-o,100-l-d); o++; if(o==100){ o=0; l=y; } if(l>0){ if(digitalRead(bl)==HIGH){ l--; } } ltr(100-p,100-n-d); p++; if(p==100){ p=0; n=x; l=l+10; k=k+10; } if(n>0){ if(digitalRead(tr)==HIGH){ n--; } } ltl(100-h,100-m-d);; h++; if(h==100){ h=0; m=x; k=k+10; l=l+10; } if(m>0){ if(digitalRead(tl)==HIGH){ m--; } } delay(t); } Przykładowo, nazwa funkcji ltl oznacza leg-top-left i służy do ujednolicenia określania położenia nogi, gdyż niektóre serwa położone są przeciwnie i wysoka wartość sygnału PWM oznacza dla nich przeciwne położenia. Funkcja move to gówna funkcja służąca do poruszania się. Działa ona tak, że wszystkie nogi poruszają się cały czas do tyłu, jednakże, początkowe położenia wszystkich nóg są różne. Gdy noga poruszając się do tyłu dojdzie do płożenia końcowego, podnosi się ona i przemieszcza do maksymalnego płożenia do przodu, wtedy zbliża się ona do podłoża aż do napotkania oporu odebranego przez czujnik krańcowy lub osiągnięcia pozycji maksymalnej, wtedy porusza się znów do tyłu. W ten sposób wszystkie nogi cały czas znajdują się w ruchu, który jest bardzo płynny. Brak 3 stopnia swobody w nodze wpływa jednak na to, że ślizganie jest nieuniknione. Ostatnia część kodu służy jedynie do egzekwowania funkcji move pod pewnymi warunkami. void loop() { if(analogRead(br)==LOW or analogRead(tr)==LOW or analogRead(bl)==LOW or analogRead(tl)==LOW && timer<50){ timer=200; } timer--; if(timer>0){ move(); }else{ lbl(50,50); lbr(50,50); ltl(50,50); ltr(50,50); } } Kod w funkcji loop powoduje również, że w razie podniesienia robota na pewien czas, przestaje on dalej iść. Gdy robot zostanie podniesiony, żaden czujnik krańcowy nie sygnalizuje, że stoi na ziemi, powoduje to spadek licznika timer do 0 i przejście robota w stan spoczynkowy, aż do aktywacji przez ponowne wciśnięcie któregoś czujnika. Gotowy robot Poniżej przedstawiam kilka zdjęć z postępu składania konstrukcji. Niestety nie posiadam dużo zdjęć tego projektu, gdyż serwa i mikrokontrolery szybko zmieniają u mnie właściciela. Podczas testów robot pokonał najwyższy próg o wysokości nieco ponad 4 cm. Może nie jest to imponująca wartość, ale biorąc pod uwagę, że nie może on biegać ani skakać, a maksymalna wysokość własna na jakiej znajduje się jego korpus wynosi około 4,5 cm jest to taki sam wyczyn jak pokonanie przez człowieka, z marszu, przeszkody sięgającej mu do pasa. A tu jeszcze jedno zdjęcie gotowego projektu (słaba jakość, klatka z filmu). Pozdrawiam, i czekam na pytania i porady.
  17. 4 punkty
    A co tu pisać... Ivona to nie jest, zwykły syntezator Klatta, trochę uproszczony (wywalone filtry dla 16 kHz), przystosowany do naszego pięknego języka i przełożony na C++. Kod jest na https://github.com/ethanak/ESP8266-Lektor - muszę poprawić README.md bo się lekko zdezaktualizowało (autorzy uprzejmie poprawili babola w funkcjach i2s). Karmi się go tekstem w utf-8, potrafi sterować np. paskiem led lub serwem od szczęki, może generować predeklarowane kształty ust. Da się skompilować pod Linuksem żeby posłuchać jak gada. Co do dokumentacji... chyba faktycznie coś skopali, bo nie mogę znaleźć paru rzeczy które kiedyś same się pchały w oczy.
  18. 4 punkty
    Miałem okazję pobawić się trochę płytką rozwojową, czyli https://www.seeedstudio.com/Air602-WiFi-Development-Board-p-3140.html postaram się więc napisać kilka słów o tym co zauważyłem. Zacznijmy od tego co fajne, czyli samego chip-a W600 firmy WinnerMicro. Jego opis znalazłem tutaj: http://www.winnermicro.com/en/upload/1/editor/1538987833915.pdf Układ wygląda bardzo fajnie - 1MB flash, 288kB RAM, taki nieźle wypasiony STM32, ale za bardzo niską cenę i jeszcze z WiFi. Wydaje mi się, że ten układ ma potencjał i jeszcze o nim usłyszymy. Znalazałem nawet nieoficjalne SDK i przykłady do niego: https://github.com/w600/sdk Następny etap to moduł Air602. Czyli https://m.seeedstudio.com/productDetail/3139 - moduł moim zdaniem mocno taki sobie. Po pierwsze nie ma anteny. Po drugie z 16 pinów GPIO, które oferuje W600 wyprowadzono 7. Pewnie był projektowany do użycia w większych projektach - dodajemy go do PCB i tyle. Sam w sobie chyba nie ma zastosowania. Nie dość że mało pinów to jeszcze trzeba chcieć i umieć zaprojektować antenę. No i na koniec zostaje "zestaw deweloperski", czyli to co dostałem. Płytka zawiera konwerter USB-UART, stabilizator 3.3V, antenę oraz moduł Air602. Brzmi fajnie, ale... jest trochę do niczego. Po pierwsze trzeba mieć USB-host. Nie ma dostępu do UART-a, więc nawet z Arduino tego nie zepniemy. Można podłączyć do laptopa lub Raspberry, tylko po co? Przecież WiFi i tak już jest. Oczywiście możemy kombinować, lutować itd. ale w najlepszym wypadku dostaniemy mniej niż ESP-01. W każdym razie podłączając ten zestaw deweloperski do laptopa możemy cieszyć się komendami AT i komunikacją przez WiFi. Nie jest to zbyt absorbujące, spróbowałem więc wykorzystać zestaw deweloperski do napisania własnej aplikacji. Mamy rdzeń Cortex-M3, więc zapowiadało się dobrze. Co więcej producent zestawu udostępnia własne SDK: https://github.com/SeeedDocument/Outsourcing/raw/master/113990576/AirM2M_W600_SDK_20180824.zip Niestety moja radość trwała krótko. Okazuje się, że wymagany jest kompilator Keil, a kod wynikowy jest na tyle duży, że nie wystarczy wersja darmowa. Nie miałem akurat ~2000 euro na zbyciu na zakup licencji, więc zostało mi uwierzyć na słowo, że SDK działa. Okazało się za to, że nieoficjlane SDK działa z gcc. Udało mi się więc chociaż przykład z migającą diodą uruchomić. Podsumowując: * zestaw deweloperski niezbyt nadaje się do własnych projektów, a moduł wymaga sporo pracy i umiejętności * dostępny firmware działa na komendach AT * oprogramowanie użytkowe jest po chińsku... seedstudio oferuje obrazkową instrukcję zamiast tłumaczenia http://wiki.seeedstudio.com/Air602_Firmware_Programming_Manual/ * SDK wymaga licencji na Keil 5 * dostępne jest nieoficjalne SDK, które działa z gcc, ale kurs podstaw mandaryńskiego jest mocno wskazany Moim zdaniem W600 to bardzo ciekawy układ. Niestety jest na takim etapie jak ESP8266 było kilka lat temu. Jeśli pojawi się lepsze oprogramowanie, będzie pewnie ciekawą konkurencją. Niestety to co zaoferowało seeedstudio wymaga jeszcze sporo poprawek.
  19. 3 punkty
  20. 3 punkty
    EuroPython za nami, do tego kilka lokalnych warsztatów z dziećmi i plany mi się trochę zmieniły. Okazuje się, że PewPew jest bardzo fajną platformą do nauki, bo jest tanie, wygląda prosto (więc nie odstrasza) i co najważniejsze, łatwo z nią zacząć. Niestety ma jeden bardzo poważny problem — żeby zobaczyć konsolę, a więc też i komunikaty o błędach z naszego programu, to trzeba albo użyć specjalnego edytora, który ma konsolę szeregową, albo osobnego programu. Do tego dochodzą problemy z uprawnieniami pod Linuksem i ze sterownikami pod Windows 7 i robi się skomplikowanie. Ludzie debugują metodą wpatrywania się w swój kod i zmieniania losowych rzeczy, co nie jest najlepsze. Zatem potrzebujemy jakiegoś sposobu na wyświetlenie komunikatów o błędach. Przewijanie komunikatu, tak jak to robi Micro:bit, niestety się nie sprawdza — nie dość, że nikt tego nie czyta, to jeszcze spowalnia to eksperymentowanie, bo trzeba poczekać aż się przewinie. Zatem zacząłem patrzeć na alternatywy dla macierzy 8x8 i okazało się, że wyświetlacze TFT mocno staniały — taki 1.8-calowy o rozdzielczości 160×128 można dostać niewiele drożej, niż moje macierze, w okolicach 1.5 USD. Zatem postanowiłem odgrzebać mój stary projekt konsolki, napisać do niej bibliotekę emulującą wyświetlacz 8×8 na ekranie, żeby wszystkie stare gry i tutoriale działały, do tego dołożyć moją bibliotekę do gier z µGame, bo czemu nie, skoro wyświetlacz podobny. Zacząłem z tym wszystkim eksperymentować, usuwając przy tym wszystkie niepotrzebne części, żeby było jak najtaniej i wyszło mi coś takiego: Urządzenie jest wielkości karty kredytowej. Zamiast SAMD21 jest SAMD51, bo jest szybszy i ma znacznie więcej pamięci RAM, której najbardziej mi w moich grach brakowało. Za to nie ma dodatkowej pamięci flash i używa połowy tej wbudowanej w mikrokontroler. Zamiast głośnika ze wzmacniaczem jest proste (i ciche) piezo — nie chcemy mieć kakofonii podczas warsztatów i lekcji. Wyświetlacz, zasilanie z dwóch małych "paluszków" i to w zasadzie tyle. Żeby ładnie wyglądało i żeby trochę ochronić przed brutalnym traktowaniem dodałem obudowę wyciętą laserem z akrylu, wraz z nakładkami na przyciski. Na dole wyprowadzone są dodatkowe piny, tak jak w PewPew, więc można podłączać rzeczy. Na jednym z nich jest audio, więc jak ktoś koniecznie chce ten wzmacniacz i głośnik (albo słuchawki), to może sobie dospawać. Zdjęcie przedstawia prototyp numer sześć. Trochę ich było po drodze: W tej chwili czekam na wycięcie ostatecznej wersji (jak dobrze pójdzie) obudowy, z trochę większymi przyciskami i okrągłymi przyciskami fire (bo kwadratowe się obracają i nie wygląda to dobrze): Przymierzam się teraz do rozmów z potencjalnymi producentami i dystrybutorami, mam nadzieję, że ostateczna cena urządzenia będzie poniżej 20 USD za sztukę.
  21. 3 punkty
    Cześć, odpowiedź jest bardzo dobra i uzasadnienie także. Raczej rzadko używa się "podwójnych" wskaźników do poruszania się po tablicy dwuwymiarowej, łatwiej jest użyć indeksów. Niemniej warto wiedzieć jak to działa na wskaźnikach (przenoszą się te zależności także na tablice o większej liczbie wymiarów - wynika to wprost z rozmieszczenia danych tablicy w pamięci. I tak dla tablic trzy wymiarowych mamy już potrójną a nie podwójną de-referencję. To może teraz kolega zada jakieś pytanie - zobaczymy, czy uda się odpowiedzieć poprawnie Pozdrawiam
  22. 3 punkty
    Witam! Dzisiaj chciałbym zaprezentować Wam mój projekt wykonany w celu obrony inżynierskiej. Jest to mój pierwszy tak rozbudowany projekt, jak i za razem pierwszy wpis na Forbocie, więc od razu przepraszam wszystkich za wszelakie poważne błędy, które mogłem popełnić. Pomysł na niego zrodził się na 3 roku studiów na kierunku Inżynierii Biomedycznej za sprawą mojego promotora dr inż. Jarosława Zubrzyckiego, któremu chciałbym bardzo serdecznie podziękować za poświęcony czas oraz użyczenie drukarek 3D. Całość składa się ze zrobotyzowanego ramienia o sześciu stopniach swobody wraz z osobnym, prostym kontrolerem. Na ramię robota składa się: konstrukcja mechaniczna wykonana z materiału ABS na drukarce 3D Zortrax M200, uPrint SE Plus oraz taniej Creality 10S, małe łożyska kulkowe o średnicy zewnętrznej ∅13 mm i wewnętrznej ∅5 mm, śrubki oraz nakrętki o wielkości metrycznej od M2,5 do M5, część napędowa, na którą składają się serwomechanizmy: TowerPro MG-946R, TowerPro SG-5010, PowerHD HD-1501MG, TowerPro SG92R. Na kontroler składają się: obudowa wykonana z materiału ABS na drukarkach 3D wymienionych wyżej, płytka Arduino UNO Rev3 (klon zakupiony na Allegro), nakładkaprototypowa do Arduino Uno z przylutowanymi komponentami, takimi jak, przewody wyprowadzające potencjometry, LED'y, rezystory, kondensatory oraz stabilizator napięcia L7805CV, oraz sterownik serwomechanizmów Pololu Mini Maestro 12-kanałowy. Serwomechanizmy dobrałem biorąc pod uwagę ich specyfikację (napięcie zasilania) oraz opinię użytkowników wykorzystujących je w swoich projektach. Z racji wykorzystania platformy jaką jest Arduino, jak i tego, że na pracę magisterską planuje ulepszyć projekt , postanowiłem ograniczyć efektor ramienia do postaci prostego chwytaka. Następna wersja projektu zostanie wyposażona w płytkę Raspberry Pi 4B wykorzystującą efektor w postaci teleskopu z podstawową kamerą i diodą doświetlającą. Sterownik serwomechanizmów Pololu Mini Maestro wybrałem ze względu na bardzo prostą obsługę napędów i świetną współpracę układu z Arduino za sprawą dedykowanej biblioteki udostępnionej przez producenta. Sterowanie ramieniem postanowiłem zrealizować dzięki zastosowaniu kontrolera w fizycznej obudowie z zastosowaniem potencjometrów obrotowych, liniowych o wartości 20 kΩ. Dzięki takiemu rozwiązaniu można w prosty sposób zasymulować pracę podstawowego trenażera. Do sygnalizowania trybu pracy ramienia użyłem 2 LED'ów (zielonego i czerwonego) sygnalizujące podłączenie do zasilania (czerwona) oraz możliwość zmiany położenia wałów serwomechanizmów, czy też brak takiej możliwości (zielona). Sterowanie trybem pracy umożliwia przełącznik z zastosowaniem prostego filtru RC eliminującego drgania styków. Wszystkie komponenty zostały przylutowane do nakładki prototypowej, z zastosowaniem przewodów połączeniowych do płytek stykowych (wiem, nie najlepsze rozwiązanie, ale poganiający czas zrobił swoje ). Cały projekt zasilany jest za pomocą zasilacza impulsowego 12 V/ 2,5A CZĘŚĆ MECHANICZNA Po dobraniu wszystkich komponentów i upewnieniu się, że będę miał dostęp do drukarki, niezwłocznie przystąpiłem do projektowania części konstrukcyjnych w oprogramowaniu Autodesk Inventor 2018. Zamierzony projekt prezentował się następująco: Podczas projektowania efektora (chwytaka) zastanawiałem się nad zastosowaniem gotowego rozwiązania, lecz z uwagi na to, że większość znalezionych przeze mnie rozwiązań składało się z wielu komponentów, lub po prostu wizualnie mi nie odpowiadały zaprojektowałem swoje własne (trochę ułomnie, po mechanizm zębaty został zaprojektowany bez użycia modułu wbudowanego w program, ani bez przeprowadzenia potrzebnych obliczeń, ale jak na pierwszy raz nie jestem zawiedziony ). Podstawa ramienia składa się z dwóch części: statycznej oraz ruchomej. Pierwsza jest przymocowana do podstawy przy użyciu 4 wkrętów do drewna M4 i osadziłem w niej jeden z serwomechanizmów. Początkowo planowałem zastosowanie łożyska kulkowego wzdłużnego do wsparcia konstrukcji, ale po "dogłębnej" analizie konstrukcji (czyt. oszczędzanie pieniążków) osadziłem część ruchomą bezpośrednio na wale serwomechanizmu (przy użyciu aluminiowego orczyka). W części ruchomej umieściłem kolejne, dwa, serwomechanizmy odpowiedzialne za sterowanie odpowiednio ramieniem i przedramieniem manipulatora. Ruch z podstawy na przedramię przekazywany został dzięki zastosowaniu ogniwa łączącego "bark" z "łokciem". W "łokciu" osadziłem kolejny serwomechanizm odpowiedzialny za ruch obrotowy przedramienia wokół własnej osi. Na końcu przedramienia, w nadgarstku umieściłem mały serwomechanizm odpowiedzialny za ruch nadgarstka oraz takie same serwo sterujące efektorem (chwytakiem). Przed przystąpieniem do druku 3D elementów ramienia przeprowadziłem analizę MES konstrukcji manipulatora. Manipulator obciążyłem siłą działającą pionowo w dół o wartości 1,5 N, przymocowaną do ramion chwytnych efektora, co symbolizowało obciążenie o wadze około 150g. W efekcie uzyskałem wynik dający wskaźnik bezpieczeństwa konstrukcji w wysokości powyżej 11 (0 fatalnie, 15 max), co świadczy o tym że zaprojektowana konstrukcja jest sztywna i wytrzymała na trwałe odkształcenia. Największe naprężenia wystąpiły na ramionach chwytnych efektora i wynosiły 1,55 MPa. Obudowę kontrolera podzieliłem na 3 części, aby było łatwiej ją wydrukować na drukarce 3D. W panelu górnym umieściłem sześć otworów montażowych na potencjometry liniowe oraz dwa na kolorowe LED'y i jeden większy na przycisk. Dolna część obudowy podzielono na 2 elementy. W jednym z nich umieszczono otwory umożliwiające dostęp do złącz płytki Arduino oraz podłączenie serwomechanizmów do sterownika. UKŁAD STEROWANIA Realizację układu sterowania rozpocząłem od zaprojektowania schematu działania konstrukcji oraz schematu podłączenia wszystkich elementów: Mając gotowy schemat przystąpiłem do realizacji fizycznego układu. Całość prezentuje się następująco: Kod sterujący projektem został napisany w środowisku Arduino IDE, z wykorzystaniem dedykowanej biblioteki do sterownika serwomechanizmów Pololu Mini Maestro: #include <PololuMaestro.h> #include <SoftwareSerial.h> #define pot1 0 //podstawa #define pot2 1 //bark #define pot3 2 //staw łokciowy #define pot4 3 //przedramie #define pot5 4 //ndagarstek #define pot6 5 //chwytak #define sw1 9 //przycisk #define led_g 8 //zielona dioda SoftwareSerial sterownikSerial(10,11); //obiekt treansmisji szeregowej (pin 10 RX, pin 11 TX) MiniMaestro sterownik(sterownikSerial); //obiekt umozliwiający komunikacje ze sterownikiem int val1 = 0; int angle1 = 0; int w1 = 0; int val2 = 0; int angle2 = 0; int w2 = 0; int val3 = 0; int angle3 = 0; int w3 = 0; int val4 = 0; int angle4 = 0; int w4 = 0; int val5 = 0; int angle5 = 0; int w5 = 0; int val6 = 0; int angle6 = 0; int w6 = 0; //===================================PĘTLA KONFIGURACYJNA=================================================== void setup() { //Serial.begin(9600); //urochomienie transmisjii szeregowej w razie potrzeby komunikacji z komputerem sterownikSerial.begin(9600); //uruchomienie transmisjii szeregowej w celu komunikacji ze sterownikiem pinMode(led_g,OUTPUT); pinMode(sw1,INPUT); //brak konieczności zastosowania trybu INPUT_PULLUP ze względu na zastosowanie w układzie rezystora podciągającego digitalWrite(led_g,LOW); //dioda zielona domyślnie jest zgaszona } //========================================PĘTLA GŁÓWNA======================================================= void loop() { val1 = analogRead(pot1); //odczyt danych z potencjoetrów oraz mapowanie otrzymanych wartości angle1 = map(val1,0,1023,2000,10000); //na zakres ruchu poszczególnych serwomechanizmów (jednostka: 0,25us) val2 = analogRead(pot2); angle2 = map(val2,0,1023,2000,10000); val3 = analogRead(pot3); angle3 = map(val3,0,1023,2000,10000); val4 = analogRead(pot4); angle4 = map(val3,0,1023,2000,10000); val5 = analogRead(pot5); angle5 = map(val3,0,1023,2000,10000); val6 = analogRead(pot6); angle6 = map(val3,0,1023,2000,10000); if(digitalRead(sw1) == 0){ //Jeżeli przycisk jest wciśnięty, zielona dioda się świeci oraz digitalWrite(led_g,HIGH); //możliwe jest sterowanie serwonapędami. if(abs(angle1 - w1) < 15) //Jeżeli różnica pomiędzy dwoma kolejnymi wartościami jest mniejsza o 15 jednostek sterownik.setTarget(0,0); //to sygnał nie jest wysyłany do sterownika. else{ sterownik.setTarget(0,angle1); w1 = angle1;} if(abs(angle2 - w2) < 15) sterownik.setTarget(1,0); else{ sterownik.setTarget(1,angle2); w2 = angle2;} if(abs(angle3 - w3) < 15); //sterownik.setTarget(2,0); else{ sterownik.setTarget(2,angle3); w3 = angle3;} if(abs(angle4 - w4) < 15) sterownik.setTarget(3,0); else{ sterownik.setTarget(3,angle4); w4 = angle4;} if(abs(angle5 - w5) < 15) sterownik.setTarget(4,0); else{ sterownik.setTarget(4,angle5); w5 = angle5;} if(abs(angle6 - w6) < 15) sterownik.setTarget(5,0); else{ sterownik.setTarget(5,angle6); w6 = angle6;} } else{ //Jeżeli przycisk nie jest wciśnięty, następuje zgaszenie zielonej diody, a sterowanie digitalWrite(led_g,LOW); //serwomechanizmami jest niemożliwe. } } PREZENTACJA DZIAŁANIA Poniżej zamieszczam krótkie wideo przedstawiające działanie całej konstrukcji. PODSUMOWANIE Tak prezentuje się wykonany przeze mnie projekt. W przyszłości planuje wymienić płytkę Arduino UNO na Raspberry Pi 4, serwomechanizmy na silniki krokowe, efektor w postaci chwytaka na wysuwany teleskop z kamerą na jego końcu oraz drastyczną przebudowę konstrukcji mechanicznej . Jestem świadomy wszystkich uproszczeń jakie popełniłem i na pewno niektóre kwestie mogłem wykonać lepiej (lub po prostu inaczej), lecz z powodu małego zasobu czasowego lub pod wpływem bliżej nieokreślonych emocji postawiłem na rozwiązania zaprezentowane wyżej. Z góry dziękuję za konstruktywną krytykę i cenne uwagi i wskazówki na przyszłość. Pozdrawiam mocno!
  23. 3 punkty
    A po co tam JSON? Natywnym obiektem w C/C++ jest struktura, nie trzeba kombinować. Przykładowo: struct ramka { uint16_t potencjometr[4]; uint16_t klawisze; } ramka; // wypełniamy ramkę danymi, np.: ramka.potencjometr[0] = analogRead(A0); ramka.potencjometr[1] = analogRead(A1); ramka.potencjometr[2] = analogRead(A2); ramka.potencjometr[3] = analogRead(A3); ramka.klawisze = digitalRead(2); // no i wysyłamy: Serial.write((const uint8_t *)&ramka, sizeof (ramka)); A po stronie odbiorczej mamy coś analogicznego: Serial.readBuffer((uint8_t *)&ramka, sizeof(ramka)); Pomijam tu oczywiście problem synchronizacji, czy wysyłania różnych typów ramek, chodziło mi tylko o zasadę.
  24. 3 punkty
    Kąt elektryczny dotyczy wirującego pola magnetycznego, a kąt mechaniczny wirnika. Silniki BLDC często mają zwielokrotnioną ilość biegunów magnetycznych - krotność k. Wirnik podąża za wirującym polem magnetycznym, ale niekoniecznie kąt obrotu musi być w stosunku 1:1. Dla przykładu jeśli krotność k = 4 to 1 obrót elektryczny pola magnetycznego spowoduje tylko 1/4 obrotu mechanicznego wirnika. Należy pamiętać, że zwiększenie krotności uzwojenia to nie to samo co zmiana ilości faz w silniku.
  25. 3 punkty
    Tak, tylko to jest znów pewien przypadek szczególny w którym liczby jakie dodajesz do ułamkowego akumulatora fazy (tak, to jest właśnie on ) będą miały postać 1/2, 1/3, 1/4, 1/5 itd. Wtedy rzeczywiście będziesz odczytywał tę samą próbkę 2, 3, 4, 5 itd razy, ale po co się ograniczać? Ani to w niczym nie upraszcza programu ani nie umożliwia generowania częstotliwości w szerokim zakresie z małym rastrem. A jeśli chcesz mieć krok 0.625 (czyli 5/8) albo 2.828125 (czyli 2 i 53/64)? Obie te liczby mają skończone rozwinięcie dwójkowe na mniej niż 8 bitach i zaaplikowane do naszego DDSa z bezwzględną precyzją dadzą odpowiednio 97.65625Hz i 441.89453125Hz. A przecież to prosty programik z jedną, 16-bitową zmienną licznika gdzie za pomoca trywialnego dodawania niecałkowitych kroków dostajesz zakres od 0.61Hz (0x0001) do 2.5kHz (0x1000) z rastrem 0.61Hz. Pomysł jest tak prosty i efektywny, że żal go nie wykorzystać, prawda? Jak rozumiem Twój pomysł polega na tym, że po prostu odliczamy co ile próbek wysłać kolejną pozycję z tablicy. Zadziała, ale nie wiem co to daje, bo ani to prostsze ani lepsze. Akumulator fazy robi to, i wiele więcej. Wszystko zależy od liczby jaką dodajesz. Bardzo istotnym elementem DDSa jest analogowy filtr wyjściowy. Musi to być porządnie zrobiony układ tnący ostro trochę poniżej połowy częstotlwości próbkowania. W prostych zabawkach można stosować jakieś kondensatorki i oporniki, w lepszych urządzeniach dawać filtry aktywne a w tych najbardziej wypasionych trzeba sięgać po scalone filtry z przełączanymi pojemnościami. Takie coś kosztuje z 10 USD, ale za to jest filtrem Czebyszewa np. 8 rzędu więc tnie ostro, a jego częstotlwość ustalasz zegarem cyfrowym. Bez takiego stopnia wyjściowego DDS produkuje przebiegi bardzo zniekształcone i zawierające sporo harmonicznych, których zawartość jest niestety różna w zależności od ustawionego kroku. Tak więc niektóre częstotliwości z DDSa będą ładniejszą sinusoidą a niektóre będą poszarpane, co jest chyba zgodne z intuicją. Filtr analogowy to wycina i każdemu daje równą szansę Przy okazji: puszczając kilka DDSów równolegle, korzystających oczywiście wspólnie z tego samego przerwania od jednego timera i tym samym jednej, wspólnej częstoliwości próbkowania oraz sumując ich sygnały wyjściowe jeszcze w procesorze, można zupełnie spokojnie zrobić polifoniczne organki np. na Arduino mogące grać rozbudowane akordy a nie tylko "Wlazł kotek na płotek" jednym palcem. A mając kilka tablic różnych sygnałów, można łatwo przełączać "brzmienia", bo jednak czysta sinusoida jest akustycznie mało ciekawa..
  26. 3 punkty
    Nie ma czegoś takiego jak zasilacz halogenowy. Co to ma na wyjściu? Prąd stały czy zmienny? Podasz jakieś konkretne parametry? Być może zasilacz musi być obciążony jakimś minimum, i wtedy metr paska to za mało i albo drugi zasilacz, albo sztuczne obciążenie może byc potrzebne. Ale tych byćmożów to jest mnóstwo wielce za dużo
  27. 3 punkty
    Brymena znam tylko z opinii w internecie. Jeśli chcesz grzebać w instalacji elektrycznej budynku to zostałbym przy Brymenie, ze względu na zastosowane zabezpieczenia, chodzi mi o bezpieczeństwo użytkownika. Miernik nie musi być jakiś super dokładny, do serwisowania i uruchamiania różnych urządzeń wystarczy. Wydaje mi się też, że będzie go trudniej uszkodzić niż Uni-T. Możesz zobaczyć mierniki z serii BM23x. Droższe alternatywy, stawiając na pierwszym miejscu bezpieczeństwo, to Fluke lub Keysight. Mam dwa mierniki UT61E, jeden kupiony rok lub dwa lata po pokazaniu się tego modelu, a drugi parę lat później. Z zewnątrz takie same, w środku zupełnie inne, więc myślę, że Uni-T to jest tak, że nie wiadomo na co się trafi. Starszy miernik. Nowszy miernik. Na obu ten sam napis kategorii miernika. Żadna poważna firma w ten sposób nie postępuje (chodzi o napis na obudowie, te same klasy przy dwóch różniących się znacznie zabezpieczeniach w obu miernikach). Pierwszy ma tylko namiastkę zabezpieczeń w postaci termistorów i mniejsze, objętościowo, bezpieczniki. Nie wiem jak to ma działać skoro nie ma warystora. Chyba, że za warystor służy usmażona elektronika miernika i użytkownik jest bezpieczny, a miernik do wyrzucenia. Drugi ma poprawione zabezpieczenia, więcej termistorów, dodane warystory i większe bezpieczniki. W obu brakuje dużego wysokonapięciowego rezystora zabezpieczającego wejście woltomierza tak jak to jest u innych producentów. W momencie przepięcia, już po zwarciu przez warystory ten rezystor powinien wytrzymać i wstępnie ograniczyć prąd przepięcia dopóki nie zagrzeją się termistory i spowodują dalszy spadek prądu. Tutaj jest jeszcze trzecia wersja. Brak wlutowanych warystorów, ale człowiek wydaje się tym nie przejmować. Mniejsze, takie jak w moim zielonym bezpieczniki. Oba mierniki oczywiście działają, ale nie były poddawane żadnym ekstremalnym próbom, zwykłe pomiary bez kręcenia pokrętłem, jak każe instrukcja, przy podłączeniu do badanego układu. Może UT-139C robią w jednej wersji, stałej wersji. Ja, niezależnie jak dobrą i niedocenianą firmą jest Uni-Trend, chyba następnego Uni-T bym nie kupił. Bo to może być loteria. Chyba, że coś do 60zł do pomiarów przy bezpiecznym napięciu.
  28. 3 punkty
    Przyszła pora na zbudowanie czegoś jeżdżącego a, że jakiś czas temu trochę spodobały mi się linefollowery to stwierdziłem, że i ja takiego zbuduję. Prezentowany robot to w sumie jego druga wersja, pierwsza była trochę niedoskonała i nie wyszła z fazy alfa, za to od niej wzięła się nazwa tego robota czyli „Grzmot” (po prostu tamten był jeszcze większy i cięższy a przede wszystkim brzydszy). Mechanika Całość oparta jest na dużej płytce uniwersalnej o wymiarach 150x90 na której znajdują się wszystkie elementy mechaniczne oraz elektroniczne. Napęd stanowią dwa silniki Pololu z przekładnią 30:1, koła to również firma Pololu, 32x7, do tego plastikowe mocowania silników. Przednie ślizgacze są zrobione z tego co akurat było pod ręką, kilka warstw kartonu przyklejonych na kropelkę. Działa zadziwiająco dobrze i jeszcze się nie urwało. Elektronika Mózgiem robota jest arduino pro mini, sterownik silników to L293D (wiem, dinozaur ale to nie jest konstrukcja na zawody tylko do nauki, wystarcza w zupełności). Czujniki linii to 5x pojedynczy moduł z czujnikiem ktir0711s, które są przylutowane za duży, metalizowany otwór do podłużnych padów na krawędzi płytki uniwersalnej (odczytywane analogowo). Do tego z przodu znajduje się cyfrowy czujnik odległości sharp, planowo miał służyć do wykrywania przeszkód jednak stanęło na tym, że używam go do startowania i stopowania robota (czasem nawet jak wpadnie na przeszkodę to też się zatrzyma :P). Sekcja zasilania zaczyna się od gniazda na akumulator, tutaj t-deans, dalej włącznik zasilania, dioda zabezpieczająca i stabilizator 7805 do elektroniki oraz przetwornica lm2596 (trochę nie spełniła oczekiwań) do zasilania silników. Do tego na płytce znajdują się trzy diody led (czerwona wskazuje zasilanie, dwie są podłączone do mikrokontrolera) oraz microswitch, akurat nie wykorzystywany. Jedno co na mi przeszkadza w tej części to gniazdo zasilania, którego ni jak nie dało się wlutować bezpośrednio w płytkę i musiałem to robić przez krótkie odcinki przewodów i odrobinę kleju na gorąco. Na szczęście nie psuje się, nie łamie a działa bardzo dobrze. Ogólnie to jak ktoś chce coś takiego zbudować ale nie chcę za bardzo w to inwestować to polecam taki sposób budowy, tzn na płytce uniwersalnej. Dzięki temu jest dużo szybciej niż z projektowaniem i wykonaniem pcb a ewentualne poprawki i przeróbki też są łatwe do wykonania. Wiadomo, że jak chcesz budować bolid na zawody no to czegoś takiego nie użyjesz ale do prototypowania jest super. Całość zasilana z dwu celowego akumulatora litowo polimerowego o pojemności 500mAh. Schemat jako taki nigdy nie powstał, całość była robiona na bieżąco, pinologię można wyczytać ze źródeł programu (w załączniku). Oprogramowanie Algorytm sterowania to PD oparte w dużej części na artykule batona z forum z tym, że dostosowany do arduino. W obecnej wersji samą część regulatora oparłem o bibliotekę pid, uruchomienie jest proste i efekty są widoczne dosyć szybko. Oczywiście polecam najpierw przyjąć trochę teorii o tym regulatorze a dopiero potem siadać do programowania. Osobiście nie jestem wielkim fanem matematyki więc po prostu wolę uruchomić bibliotekę i poświęcić więcej czasu na inne elementy programu. Poza tym mamy fragmenty do liczenia błędu, odczytywania ADC, sterowania silnikami i włączania/wyłączania robota (taki bezpiecznik, odczytuje napięcie akumulatora i stan czujnika sharp). Z rzeczy, które mi brakuje to na pewno kalibracja, jakiś interfejs z użytkownikiem, np. moduł bluetooth i odczyt telemetrii w czasie rzeczywistym. Przemyślenia W pierwszej rewizji tego robota silniki były zasilane bezpośrednio z akumulatora przez co strojenie regulatora było dosyć kłopotliwe bo parametry jezdne się dosyć dynamicznie zmieniały. W ramach późniejszej modyfikacji dodałem moduł przetwornicy (dlatego tak średnio pasuje i przechodzą pod nią przewody) i myślałem, że wyeliminuje to do pewnego poziomu problem zmiennej dynamiki. Niestety rzeczywistość mnie trochę zaskoczyła, napięcie na wyjściu to około 6V gdy akumulator ma jeszcze 7.5-8V to robot już wyraźnie traci werwę (napięcie się nie zmienia). Na szczęście mam dwa akumulatorki więc jak jeden jeździ to drugi się ładuje i tak się zmieniają co kilkanaście minut testów (nie ciągłej jazdy). Drugi problem to złe rozłożenie masy. Zdarza się, że koła tracą przyczepność i zaczynają buksować i robot się zatrzymuje. Położenie rolki taśmy izolacyjnej na wysokości silników rozwiązuje ten problem. Do tego jeszcze ciekawostka, wydaje mi się, że robot lepiej radzi sobie na samym regulatorze P (przynajmniej na mojej, domowej trasie). Owszem, oscyluje ale i tak wydaje się, że jedzie średnio szybciej niż po dłuższej chwili strojenia metodą z artykułu. Postaram się to pokazać na filmach, liczę, że bardziej doświadczeni coś podpowiedzą (chciałbym tutaj jeszcze poeksperymentować). Jeżeli macie jakieś pytania albo czegoś nie napisałem/napisałem niezrozumiale to proszę o zwrócenie uwagi, odpowiem i uzupełnię opis. Grzmot2.0.zip
  29. 3 punkty
    Tylko że boty nie bawią się w skanowanie portów jakichś paszczatych serwerków tylko wbijają się na port 22. Jak długo pracuję jako admin (a to już paręnaście lat) nie widziałem aby ktoś mi się próbował wcinać na port na który stoi mój SSH. Poza tym zmiana portu nie tyle podnosi bezpieczeństwo, co eliminuje niepotrzebne obciążanie systemu przez wszelakie zombiaki z Kazachstanu. Klucze publiczne możesz sobie wsadzić tam gdzie słońce nie dochodzi, jeśli musisz czasem logować się z dowolnych maszyn (np. z każdej z 20 maszyn w biurze) nie udostępniając swojego systemu każdemu, kto posadzi tyłek na krześle. Owszem, są wygodne w domciu bo nie musisz hasełka do swojej malinki bez przerwy wpisywać - i tyle. Zresztą - biorąc po uwagę że malinki zwykle rosną w ogródku za furtką o nazwie NAT, dopóki nikt Ci się do sieci nie włamie to na malince możesz równie dobrze zainstalować serwer telnetu bez hasła, nie wpłynie to w żaden sposób na bezpieczeństwo. A zabezpieczanie routerów to już na pewno nie temat do tego wątku.
  30. 3 punkty
    Witam! Chciałbym się pochwalić moim pierwszym stworzonym projektem, a mianowicie systemem monitorowania środowiska. Interesuję się IoT i jego obszarami działania. Stworzyłem system, który składa się z urządzenia pomiarowego, chmury internetowej oraz aplikacji mobilnej. Struktura systemu została podzielona na 3 etapy, odpowiednia: warstwa sprzętowa, chmury i aplikacji. Warstwa sprzętowa Urządzenie ma za zadanie pobieranie danych z otoczenia oraz pobieranie ich do zewnętrznego serwera. Badane czynniki to: temperatura, wilgotność, opady atmosferyczne i ruch. Do wykonania urządzenia wykorzystano poniższe podzespoły: Arduino Uno Rev3, Czujnik temperatry i wilgotności DHT11, Czujnik ruchu PIR HC-SR501, Czujnik opadów deszczu YL-83, Moduł sieciowy Ethernet ENC28J60 mini, przewody połączeniowe, płytkę stykową. Projekt urządzenia wygląda następująco: Oraz urządzenie wykonane zgodnie z projektem: Następnie funkcje sensorowe urządzenia zostały przetestowane. Na płytkę został wgrany poniższy kod: #include <dht11.h> #define CzujnikTempWilgPin 2 //definicja numerów pinów #define CzujnikOpadAnalogPin A0 #define CzujnikOpadDigitalPin 4 #define CzujnikRuchPin 8 int wartosc_A0; int wartosc_D0; int wilgotnosc; int temperatura; int ruch; dht11 DHT11; int interwal = 30000; void setup() { Serial.begin(9600); //inicjalizacja monitora szeregowego pinMode(CzujnikOpadDigitalPin, INPUT);//konfiguracja zachowania pinów pinMode(CzujnikRuchPin, INPUT); } void loop() { DHT11.read(CzujnikTempWilgPin); //odczyt danych z czujnika DHT11 wilgotnosc = DHT11.humidity; Serial.print("Wilgotnosc (%): "); Serial.print((float)wilgotnosc, 0); temperatura = DHT11.temperature; Serial.print(" Temperatura (C): "); Serial.println((float)temperatura, 0); ruch = digitalRead(CzujnikRuchPin); //odczyt danych z czujnika ruchu if(ruch == HIGH){ Serial.println("Wykryto ruch"); } else { Serial.println("Nie wykryto ruchu"); } wartosc_A0 = analogRead(CzujnikOpadAnalogPin); wartosc_D0 = digitalRead(CzujnikOpadDigitalPin); if (wartosc_D0 == LOW) { Serial.print("DESZCZ PADA Z INTENSYWNOŚCIĄ "); Serial.println(wartosc_A0); } else { Serial.println("DESZCZ NIE PADA"); } delay(interwal); } Test monitorowania parametrów: Konieczna była regulacja czujników, aby mierzone wartości były jak najbardziej dokładne. Warstwa chmury Jako chmurę przechowującą i analizującą dane wybrano serwis Thingspeak.com. Jako sposób komunikacji wybrano interfejs REST API. W pierwszej kolejności założono konto oraz publiczny kanał wyposażony w 5 pól: temperatura, wilgotność, ruch, opady atmosferyczne i intensywność opadów. Sprawdzono również klucze danych odpowiedzialne za zapis i odczyt danych. Poniższa grafika przedstawia przesłane dane z urządzenia pomiarowego. Warstwa aplikacji Końcowym elementem systemu jest urządzenie z systemem Android. Stworzono aplikację, dzięki której możliwe jest połączenie z kanałem na thingspeak.com oraz pobranie danych. Aplikacja została zaopatrzona we wszystkie wyżej wymienione wykresy oprócz wykresu intensywności opadów. Projekt aplikacji został przedstawiony powyżej. Wszystkie wykresy zostały umieszczone w panelu przesuwnym. Do stworzenia wykresów wykorzystano biblioteki graficzne na system android: biblioteka do tworzenia kanału thingspeak.com oraz bibliotekę do tworzenia wykresów. Cały kod stworzonej aplikacji na system android. Agregacja całego systemu Następnie przyłączono urządzenie do sieci oraz został wgrany poniższy kod: #include <dht11.h> #include <UIPEthernet.h> #define CzujnikTempWilgPin 2 #define CzujnikOpadAnalogPin A0 #define CzujnikOpadDigitalPin 4 #define CzujnikRuchPin 8 byte mac[] = { 0x54, 0x34, 0x41, 0x30, 0x30, 0x31 };//adres MAC urządzenia EthernetClient client; char server[] = "api.thingspeak.com";//adres api thingspeak int wartosc_A0; int wartosc_D0; int wilgotnosc; int temperatura; int ruch; int interwal = 30000; dht11 DHT11; void setup() { Ethernet.begin(mac); //rozpoczęcie połączenia pinMode(CzujnikOpadDigitalPin, INPUT); pinMode(CzujnikRuchPin, INPUT); } void loop() { DHT11.read(CzujnikTempWilgPin); wilgotnosc = DHT11.humidity; temperatura = DHT11.temperature; ruch = digitalRead(CzujnikRuchPin); wartosc_A0 = analogRead(CzujnikOpadAnalogPin); wartosc_D0 = digitalRead(CzujnikOpadDigitalPin); if (client.connect(server, 80)) {//składanie komendy get client.print("GET /update?"); client.print("key=POZ0YSHN2VGMKS05"); client.print("&field1="); client.print(temperatura); client.print("&field2="); client.print(wilgotnosc); client.print("&field3="); client.print(wartosc_D0); if(wartosc_D0==LOW) { client.print("&field4="); client.print(wartosc_A0); } client.print("&field5="); client.print(ruch); client.println( " HTTP/1.1"); client.print( "Host: " ); client.println(server); client.println( "Connection: close" ); client.println(); client.println(); client.stop();// } delay(interwal); } System funkcjonował prawidłowo dane były przesyłane na serwer. Następnie uruchomiono aplikację mobilną. Oto kilka screenów: Dodatkowymi funkcjami apikacji jest przesuwanie oraz przybliżanie wykresów oraz odczytywanie dokładnych wartości po kliknięciu w punkt wykresu. Mam nadzieję, że przedstawiłem to w ciekawy i przejrzysty sposób. :) Pozdrawiam
  31. 3 punkty
    Dodając krok po kroku trochę automatyki w mieszkaniu powstał projekt i realizacja sterownika rolet zewnętrznych. Główne cechy urządzenia: obsługa 7 rolet zdalny dostęp z dowolnego miejsca na świecie sterowanie przez Wifi sterowanie przez Bluetooth sterowanie przez sieć CAN automatyczny pomiar czasu pracy poszczególnych rolet harmonogram otwierania/zamykania rolet sterowanie grupowe tworzenie scen pobieranie aktualnego czasu z serwera NTP Sterownik został podzielony na dwie części, pierwsza to płytka z przekaźnikami i zasilaniem, druga płytka to układ sterowania wraz z modułami komunikacyjnymi. Główne elementy wykorzystane w sterowniku to: STM32F103C8T6 jako moduł Bluepill Moduł Wifi ESP-12 Bluetooth HC-05 Największym wyzwanie okazało się wykrywanie zakończenia pracy rolety. Było to niezbędne do automatycznego pomiaru czasu pracy, które jest wykorzystywane do określania pozycji pośrednich. Na początku testowałem wykrywanie prądu z wykorzystaniem modułu ACS711, ale niewielki prąd pobierany przez roletę podczas pracy powodował niestabilne pomiary z układu ACS711. Drugim pomysłem było wykorzystanie przekładników prądowych. Pomiary były stabilne, ale to rozwiązanie odpadło ze względu na fizyczne rozmiary takich przekładników, potrzebowałem użyć ich aż siedem sztuk. Ostatecznie zastosowałem rozwiązanie polegające na spadku napięcia na diodach, które aktywuje transoptor PC814. Rolety które posiadam mają wewnętrzne zabezpieczenie przed podaniem napięcia na oba uzwojenia silnika (góra, dół), jednak tak zaprojektowałem układ, aby sprzętowo nie było to możliwe. Pokazane jest to na poniższym rysunku. Program został napisany w C++ z wykorzystanie Arduino Core. ESP-12 pełni rolę konwertera komunikacyjnego, od strony wifi oferuje RestApi, konwertuje otrzymane wiadomości/zapytania na komunikację uart i wysyła do głównego procesora STM32. Na drugim porcie uart w STM32 jest podobna komunikacja z wykorzystaniem modułu bluetooth. Moduł BT aktualnie służy do przeglądania bieżących logów. Ponadto moduł posiada opcję komunikacji z wykorzystaniem sieci CAN, jestem bardziej fanem rozwiązań przewodowych tam gdzie jest to możliwe. Jak w mieszkaniu pojawi się więcej elementów automatyki to będę chciał całość przepiąć na sieć CAN zamiast Wifi. Sterowanie modułem odbywa się jak wspomniałem wyżej zapytaniami REST, na Banana Pro posiadam domowy serwer www, dołożyłem do niego prostą stronę w PHP, która pozwala w wygodny sposób wysyłać zapytania do sterownika. Do połączenia się ze sterownikiem poza domową siecią wykorzystuje OpenVPNa.
  32. 3 punkty
  33. 3 punkty
    Wstęp Globalizacja światowej gospodarki oraz gwałtowny rozwój techniczny w XX wieku spowodował bardzo duże udoskonalenie metod produkcji, gdzie przemysłowe innowacje pozwoliłyby na produkcję wysokiej jakości dóbr przy dążeniu do jak najniższej ceny wyrobu końcowego. Jednym z owoców tego postępu jest CNC - computerized numerical control / komputerowe sterowanie urządzeń numerycznych, opracowane w MIT w USA w roku 1949. Podstawową różnicą między obróbką ręczną a CNC jest zastąpienie pracownika sterującego maszyną, komputerem, który z wykorzystaniem czujników (indukcyjne liniały pomiarowe, przełączniki krańcowe, elementy optoelektroniczne) i urządzeń wykonawczych (silniki krokowe / serwomechanizmy / serwonapędy) będzie na bieżąco kontrolował przemieszczanie narzędzia (na przykład frezu, noża tokarskiego czy palnika plazmowego/laserowego) zgodnie z przygotowanym wcześniej na podstawie rysunku technicznego zestawem instrukcji sterujących, pozwalając, w porównaniu do metod konwencjonalnych, na uzyskanie większej wydajności, wyższej dokładności i powtarzalności przy mniejszej ilości pracowników (park maszynowy składający się z kilku obrabiarek może obsługiwać jeden programista) oraz redukcji kosztów. Założenia projektu i dane techniczne Celem projektu było zbudowanie sterowanego numerycznie plotera rysującego, który: jako końcówkę wykonawczą wykorzystywałby długopis o średnicy 10mm z możliwością wykorzystywania wkładów o różnych kolorach; w osiach X i Y, napędzanych przez silniki krokowe, posiadał możliwość przesuwu o 120mm; w osi Z, gdzie długopis poruszany przez serwomechanizm modelarski stanowiłby jednocześnie prowadnicę, posiadałby skok kilku milimetrów; wykorzystywałby w osiach X i Y innowacyjne, bezsmarowne moduły liniowe firmy Igus® DryLin®; byłby niski dzięki konstrukcji opartej o stół krzyżowy z wysięgnikiem; był względnie dokładny, z ostateczną dokładnością pozycjonowania na poziomie +/- 0,5mm. Dane techniczne: konstrukcja stołu krzyżowego z wysięgnikiem, oparta o moduły liniowe wykorzystujące prowadnice o średnicy 10mm i śrubie trapezowej o średnicy 10mm i skoku 2mm; moduły liniowe napędzane silnikami krokowymi NEMA16; śruby modułów liniowych połączone z osiami silników krokowych poprzez sprzęgła elastyczne; pole robocze – kwadrat o boku 120mm; uproszczona budowa osi Z - długopis bez możliwości precyzyjnego przesunięcia – podniesienie / opuszczenie dzięki zastosowaniu serwomechanizmu i gumki recepturki; możliwość zerowania (homing) dzięki wykorzystaniu przełączników krańcowych; własnoręcznie wykonany sterownik oparty o Arduino Nano i open-source’owe oprogramowanie GRBL; całość zasilana zasilaczem 12V o maksymalnej wydajności prądowej 4A. Mechanika i oprogramowanie Mechanika maszyny sterowanej numerycznie, poza koniecznością stosowania napędów, w których możliwe będzie zadawanie ściśle określonego przesunięcia, nie różni się wiele od tej stosowanej w konwencjonalnych maszynach. Pierwszym krokiem w przypadku „Pioneer’a” było wybranie modułów liniowych (SLW o maksymalnej długości przejazdu wózka 150mm) firmy Igus®, które pozwalają zamienić ruch obrotowy pokrętła na ruch liniowy wózka dzięki śrubie trapezowej i odpowiedniej nakrętki, zamocowanej wewnątrz wózka. Standardowo nakrętki są wykonywane ze stali nierdzewnej bądź brązu, dla których koniecznością jest smarowanie, ponadto są stosunkowo ciężkie i z biegiem czasu zużywają się. Igus® opracował innowacyjne tworzywo sztuczne iglidur®, które jest doskonałe dla nakrętek, łożysk ślizgowych i panewek pracujących przy małych i średnich obciążeniach dzięki eliminacji wspomnianych wad. Dwa takie moduły zostały ze sobą połączone w stół krzyżowy za pomocą aluminiowego elementu z blachy o grubości 1,5mm – najpierw wycięto odpowiedni prostokąt na gilotynie, następnie otwory nawiercano wiertarką kolumnową, korzystając z rysunku technicznego stworzonego w programie Solid Edge. Drugim programem CAD wykorzystanym do budowy plotera, był Google SketchUp, w którym zaprojektowane zostały wszystkie elementy drukowane później na drukarce 3D W niskobudżetowych konstrukcjach CNC stosuje się silniki krokowe, ze względu na to, że jest to najtańsza w porównaniu do prostoty sterowania opcja napędu, który pozwalałby na precyzyjne zadawanie kąta, o jaki obrócić ma się wał – wykorzystane silniki NEMA16 firmy MicroStep pobierają prąd rzędu 800mA i posiadają rozdzielczość 200 kroków na obrót – zatem pojedynczy impuls obraca wał o 1,8° (teoretycznie zatem, jeżeli skok śruby wynosi 2mm, to dokładność pozycjonowania wózka wyniesie 0,01mm). Osie silnika krokowego (średnica 5mm) i śrub (średnica 10mm) połączone są aluminiowymi sprzęgłami elastycznymi. Wykorzystane sterowniki silników krokowych to A4988 – aby wysterować silnik krokowy, potrzebne są dwa piny – DIR (kierunek obrotów) i STEP (ilość impulsów podanych na to złącze jest równa ilości kroków, o jakie przesunie się wał silnika). Pozwalają one również na tak zwane mikrokroki – w zamian za mniejszy moment obrotowy pozwalają na nawet 16-krotne zwiększenie rozdzielczości, jednak ze względu na bardzo małą odległość przesuwu wózka w osi X bądź Y po podaniu jednego impulsu na wejście STEP (wspomniane 0,01mm) nie wykorzystano tej opcji w tym projekcie (na zdjęciu sterownik wraz z radiatorem). W początkach CNC wysterowaniem step-stick’ów zajmował się bezpośrednio komputer PC, gdzie do pinów portu LPT podłączone były piny sterowników silników krokowych – nie jest to dobre rozwiązanie, gdyż komputer PC musi jednocześnie obsłużyć wiele procesów, a zatem mogą pojawić się błędy w rysowaniu krzywych (wówczas ruch osi X oraz Y musi ze sobą korelować). Wady te można wyeliminować poprzez zainstalowanie systemu operacyjnego czasu rzeczywistego, na przykład LinuxCNC, jednak w zastosowaniach niskobudżetowych optymalne jest wykorzystanie Arduino – oprogramowanie sterujące (GRBL) przesyła paczkami poprzez USB instrukcje do niego właśnie, a ono, pełniąc funkcję buforującą, wysterowuje silniki w sposób ciągły. GRBL to open-source’owe darmowe oprogramowanie rozwijane przez grupę hobbystów z całego świata, oferujące gotowy do wgrania wsad dla płytek Arduino oraz gotowy program sterujący, dostępny dla systemów Windows, Linux i Mac OS, GRBL Controller, który pozwala na zmianę ustawień sterownika, ręczny przesuw końcówki roboczej, wyzerowanie maszyny (jeżeli takowa posiada taką opcję („Pioneer” posiada), na przykład w postaci czujników krańcowych – po włączeniu plotera program nie wie, gdzie znajduje się końcówka wykonawcza, musi więc przesuwać wózki od poszczególnych osi tak długo, aż zareagują na ich obecność krańcówki – to sygnał, że wózek dojechał do początku osi), podgląd pliku G-Code oraz rzecz jasna przesłanie go do sterownika. G-Code dla prostych kształtów napisać można samodzielnie, bądź poprzez program graficzny (stosuję Inkscape z wtyczką MIGRBL – najpierw z grafiki rastrowej program pozyskuje kontur, który jest wektoryzowany). Następnie wtyczka zbiór taki konwertuje do listy punktów i zapisuje w postaci tekstowego pliku o rozszerzeniu .gcode Do mocowania kartki papieru (format A4) wykorzystano taśmę malarską – sprawdziła się w tej roli bardzo dobrze, kartka jest zamocowana pewnie i nie przesuwa się, a po zakończonym rysowaniu łatwo zdjąć ją ze stołu. Program GRBL jest przeznaczony przede wszystkim dla frezarek CNC, ale nie stanowi większego problemu wykorzystanie jako końcówki roboczej, zamiast wrzeciona ze zamontowanym frezem, długopisu. Przed pierwszym użyciem należy go skonfigurować, wprowadzając ustawienia, które są indywidualne dla każdej konstrukcji. Schemat Kilka zdjęć i rysunków Robot przeszedł lifting związany z zastąpieniem ciężkiej podstawy ze sklejki płytą ze spienionego PCV Podsumowanie Jestem bardzo zadowolony z konstrukcji, mimo niewielkich prędkości stanowi świetny model edukacyjny, doceniony został na I Edycji Konkursu "Elektronika - by żyło się łatwiej" - III miejsce oraz Konkursie Innowacji Technicznych w roku szkolnym 2017/18 - I miejsce na etapie rejonowym i wyróżnienie na ogólnopolskim Pozdrawiam, wn2001
  34. 3 punkty
    Witam chciałbym Wam przedstawić regułę działania regulatora PID, model ten wykonałem na studia jako projekt zaliczeniowy. Gdybyście nie chcieli czytać tego wszystkiego to możecie tego posłuchać na YouTube Regulator ten składa się z trzech członów: Proporcjonalnego (proportional) Całkującego (integral) Różniczkowego (derivative) Jego celem jest utrzymanie wartości wyjściowej na poziomie wartości zadanej. Oblicza on wartość różnicy pomiędzy parametrem zadanym a zmierzonym. Działa w taki sposób aby zredukować wartość różnicy. Stosuje się go w obiektach które poddawane są falą zakłóceń. Ja go zastosowałem w modelu piłki i belki, aby przeciwdziałał sile grawitacji. Jest to prosty model który jest niestabilny w otwartej pętli. To znaczy że jeśli kąt odchylenia belki od poziomu jest bardzo zbliżony do zera i nie ma sprzężenia zwrotnego to grawitacja spowoduje, że belka zacznie się przechylać w daną stronę i piłka w końcu z niej spadnie. Aby ustabilizować piłkę należy użyć regulatora PID, który będzie mierzył położenie piłki i odpowiednio regulował kąt nachylenia belki. W tym modelu ramię dźwigni jest przymocowane na jednym końcu belki a ramię serwomechanizmu na drugim. Gdy ramię serwomechanizmu obraca się o kąt θ to dźwignia zmienia kąt nachylenia belki o α. Rysunek przedstawiający model piłki i belki Funkcja która opisuje zależność położenia piłki R(s) od kąta serwomechanizmu θ(s) w otwartej pętli jest następująca: Miałem do wyboru albo zasymulować układ w programie simulink albo zbudować rzeczywisty model, wiadomo co wybrałem Schemat blokowy regulatora PID który implementowałem jest następujący: Oprogramowanie na komputerze do którego jest podpięta kamera, mierzy odległość piłki od zadanej pozycji, odejmując centroid piłki od połowy szerokości rozdzielczości obrazu z kamery. Na samym początku zacząłem od przygotowania modelu w programie SketchUp. Gotowa złożona konstrukcja przeze mnie wygląda następująco: Podpięcie serwomechanizmu do Arduino: Serwomechanizm został podpięty do Arduino za pomocą przewodów męsko-męskich wg poniższego schematu: Serwomechanizm Arduino czerwony kabel 5V brązowy kabel GND pomarańczowy kabel Pin 3 Następnie zaprogramowałem Arduino tak by mogło odczytywać dane po serialu i sterować serwem: 1: #include <Servo.h> 2: Servo servo; 3: int servoPin = 3; 4: int radius = 90; 5: 6: void setup() { 7: Serial.begin(115200); 8: servo.attach(servoPin); 9: servo.write(radius); 10: } 11: 12: void loop() { 13: if (Serial.available()) { 14: radius = Serial.read(); 15: servo.write(radius); 16: } 17: } Kod który oblicza odległość piłki od zadanej pozycji, dokonuje obliczenia i wysyła dane do arduino został napisany w języku Python. Do przetwarzania obrazu z kamerki wykorzystałem bibliotekę Opencv (Open Source Computer Vision Library), która jest na licencji BSD. Żeby program rozpoznał piłkę musiałem: Zdefiniować zakres barw. Lekko rozmazać obraz po przez rozmycie Gaussa. Stworzyć maskę dla danego zakresu. Na podstawie stworzonej maski znaleźć kontur. Na podstawie konturu znaleźć centroid oraz narysować linię wokół obiektu. z racji tego że kod napisany w języku Python zajmuje trochę miejsca to umieściłem go na githubie, poniższy link przekieruje do mojego repozytorium z kodem wraz z komentarzami: kod programu Wnioski które wynikły z budowy: Bardzo ważną rzeczą przy budowie konstrukcji jest eliminacja luzów które mogą się pojawić na ramieniu łączącym serwomechanizm z pochylnią jak i na łączeniu pochylni z podporą. Arduino podczas przyjmowania danych po serialu zamienia znaki na kody ASCII dodatkowo przyjmuje te dane jako String. Dlatego podczas wysyłania danych z programu należy najpierw zrzutować zmienną radius do typu całkowitego (wartości z regulatora są typu double a serwomechanizm działa na wartościach całkowitych), następnie należy to zamienić na char który potem zamieniamy na String. Przykład dla wysłania kąta równego 120 stopni 120 - kod ASCII reprezentuje znak x (mały) Znak ten jest rzutowany na String po czym jest wysyłany do Arduino po serialu Arduino przyjmuje te dane po czym zamienia każdy znak na kod ASCII - otrzymujemy 120. Maskę w bibliotece OpenCV tworzy się w przestrzeni barw HSV, dlatego musiałem wykonać konwersję z BGR na HSV Biblioteka OpenCV operuje na zmapowanych zakresach HSV. Poniżej przedstawiam tabelę zmapowanych wartości
  35. 3 punkty
    Lampy nixie to chyba najczęściej powracający temat wśród amatorskich projektów elektronicznych. Myśl o skonstruowaniu zegara z takim wyświetlaczem chodziła mi po głowie już wiele lat temu, w tym celu zaopatrzyłem się w zestaw lamp IN-14. Niestety z powodu braku czasu i dużej ilości projektów o wyższym priorytecie zadanie to ciągle było odkładane na później. Może to i lepiej, bo w międzyczasie miłośnicy amatorskiej elektroniki zyskali dostęp do całkiem ciekawych elementów, które mogłem wykorzystać w projekcie. Prezentowany zegar powstał w 2017 roku. Jego głównym elementem jest mikrokontroler Atmega644, który wykonuje wszystkie operacje związane z odmierzaniem czasu i obsługą multipleksowanego wyświetlacza. Dodatkowo zegar został wyposażony w moduł WiFi z układem ESP8266, pracujący pod kontrolą własnego programu. Zadaniem modułu jest cykliczne sprawdzanie czasu na serwerze NTP i korygowanie ustawień lokalnego RTC. Urządzenie posiada też układ scalony FT232, dodający możliwość konfiguracji przez USB. Stałe napięcie około 180V jest generowane za pomocą przetwornicy boost na układzie MC34063A. Oprogramowanie zegara zostało wyposażone w funkcję automatycznego wykrywania czasu letniego i zimowego. Na płycie czołowej znajduje się przełącznik umożliwiający włączenie trybu, w którym wyświetlany jest czas UTC - funkcja ta została dodana w związku z moimi radioamatorskimi i krótkofalarskimi zainteresowaniami. Konstrukcja została zamontowana wewnątrz obudowy ze sklejki wycinanej laserowo. Fizycznie urządzenie składa się z dwóch osobnych płyt, Jedna z nich mieści zestaw lamp nixie, druga elektronikę sterującą.
  36. 3 punkty
    Cześć, Ja wykorzystuję ROSa w moim robocie mobilnym (line follower z kamerą i sterowaniem predykcyjnym). Polecam http://wiki.ros.org/ , a później książkę 'Mastering ROS for Robotics Programming'. Polecam podane wcześniej źródła. Pod kątem OSa to ja na PC mam Ubuntu 16, a na RPi Ubuntu Mate. 'linux Willie' - co to? Ja mam strukturę taką, że PC komunikuje się z RPi (zamontowanym w robocie) przez wifi, a RPi z mikrokontrolerem (STM32F1) przez bibliotekę rosserial. Ogólnie to obsługiwane może być w sumie wszystko, zależy jaki efekt i działanie chcesz uzyskać. Nie rozumiem pytania. Polecam zadawać konkretne pytania, to uzyskasz konkretniejsze odpowiedzi
  37. 3 punkty
    Ja mam trochę inną prośbę. Moderatorowi pewnie nie wypada ubijać wątku, który poza poziomem wypowiedzi nic złego nie zawiera. Więc proponowałbym po prostu ignorować kolejne wpisy i nie karmić więcej trola (tutaj prośba do kolegi @Belferek, kończ waść wstydu oszczędź).
  38. 3 punkty
    Od dość dawna na Forbocie nie pojawił się żaden nowy robot klasy Sumo. Dlatego postanowiłem opisać swoją konstrukcję, która debiutowała na Robocompie 2015. Konstrukcja mechaniczna: Efektem prac nad robotem klasy Standard Sumo jest robot o nazwie Puszek. Mieści się on w wymiarach 20x20cm i wadze 3kg. Jego podwozie stanowi stalowa blacha o grubości 5mm. Z przodu umieszczony jest nóż ze stali HSS, który powinien wytrzymać starcia z innymi robotami. Koła mają średnicę 55mm i składają się z wydrukowanych felg i opon odlanych z silikonu. Dzięki miękkiemu silikonowi uzyskana została dość dobra przyczepność, jednak opony takie łatwo ulegają uszkodzeniom i po pewnym czasie wymagają wymiany. Każde koło napędzane jest osobnym silnikiem Robotus Titan. Zasilane są one z LiPo 4s 3.3Ah. Jednak mimo napięcia wyższego niż znamionowe, silniki są zbyt słabe, żeby robot nawiązał równą walkę z dużo mocniejszymi konstrukcjami. Niestety podczas składania okazało się, że robot będzie zbyt ciężki, dlatego blacha stanowiąca podwozie została nawiercona, co widać na zdjęciu poniżej: Elektronika: Mózgiem robota jest Arduino Mini, czyli popularna Atmega328p. Odpowiada ona za odczyty 4 czujników przeciwnika Sharp GP2Y0A21YK0F, 2 czujników linii KTIR0711S oraz odpowiednie wysterowanie silników poprzez mostki oparte na półmostkach BTS7960B. Są to najtańsze mostki H z ebay, o teoretycznie wystarczającej mocy. Jak do tej pory wszystko jest z nimi ok. Cała elektronika zasilana jest poprzez stabilizator LM7805, który wymagał założenia dodatkowego radiatora. Za odpowiednie wysterowanie silników odpowiada regulator typu P, którego sygnałem wejściowym jest błąd obliczany na podstawie odczytów z czujników przeciwnika, natomiast wyjściem jest sygnał PWM oraz kierunek obrotów silników. Kilka filmików z YT nagranych w Łodzi przez użytkownika ps19: Osiągnięcia: 1. I miejsce Robocomp 2015 2. II miejsce SumoChallenge 2015 W przyszłości planuje stworzyć konstrukcję na dużo mocniejszych silnikach, z którą będę mógł się również pokazać i powalczyć w Wiedniu.
  39. 3 punkty
    Witam wszystkich, zapewne większość użytkowników układów FPGA dochodzi do takiego momentu, że chcieliby dodać do swoich projektów możliwość niezawodnej (i w miarę szybkiej ) komunikacji z innymi systemami (np. opartymi o mikro-kontroler). Ćwiczyliśmy już komunikację układu przez UART i konwerter UART-RS485. Akurat teraz pracuję nad projektem opartym o mikro-kontroler z serii STM32F103 gdzie główna magistralą komunikacyjną jest "CAN BUS". CAN zapewnia bardzo niezawodną komunikację o prędkości do 1Mb/s na 1-nej parze skrętki (elementy zwiększające niezawodność są wbudowane w warstwę fizyczną magistrali) na duże odległości. Stąd chciałbym móc dodać obsługę magistrali CAN do moich projektów opartych na układach FPGA. Czasami po prostu potrzebujemy "peryferiów", których nie ma na naszym zestawie uruchomieniowym FPGA (np. wyświetlacz, mała klawiatura, akcelerometr, czujnik natężenia światła, wyjście audio,ADC/DAC itp). Jest dużo modułów peryferyjnych różnych firm, które można podłączyć do układów FPGA (np. moduły firmy Numato o których była mowa na forum). Możemy skorzystać także z modułów "Pmod" firmy Digilent. Mają one taką zaletę, że posiadają zunifikowany sposób komunikacji (magistrala SPI) oraz do części z nich są gotowe "IP core" (biblioteki w językach HDL). Są też w miarę dobre tutoriale firmy Digilent jak korzystać z tych modułów Pmod. Może najpierw podam link do strony gdzie można odszukać potrzebny nam moduł Pmod: https://store.digilentinc.com/pmod-modules-connectors/ Aby użyć dużej części z tych modułów musimy w naszym projekcie (FPGA) dysponować CPU - może to być sprzętowy procesor (np. ARM z układu Zynq Xilinxa) lub soft-processor(procesor zaimplementowany w układzieFPGA) jak np. Microblaze. Właśnie tego tematu będzie dotyczył ten post: połączenia soft-procesora Microblaze i "IP Cores" firmy Digilent do integracji modułów Pmod. Oczywiście istnieją odpowiedniki firmy Intel/Altera (zarówno hard-processors jak i soft-processors np. NIOSII). Ponieważ projekty, które realizuję są oparte na układach firmy Xilinx (i lepiej znam Vivado niż Quartusa) w tym poście ograniczymy się do zestawów opartych na układach FPGA tej firmy. Wszystkie projekty tu opisane są oparte na zestawie uruchomieniowym firmy Digilent "Cmod A7 35" z układem Artix 7 Xilinxa. tutaj jest link do tego zestawu: https://reference.digilentinc.com/reference/programmable-logic/cmod-a7/start?redirect=1id=cmod_a7/cm Środowiskami używanymi przeze mnie do syntezy i programowania są darmowe "Vivado 2018.2" (wersja webpack) i "Xilinx SDK 2018.2) (do programowania Microblaze w języku C. Projekty w Vivado powinny dać się łatwo dostosować do innych zestawów uruchomieniowych z układem Artix 7, jak np. "Arty S7" czy "Basys3" firmy Digilent. Aby zaznajomić się jak są zbudowane "IP Cores" dla modułów Pmod Digilenta proponuję zacząć od tej strony WWW: https://blog.digilentinc.com/introduction-to-pmod-ip-cores/ Wszystkie opisywane tu próby będą dotyczyć używania soft-procesora Microblaze z dodatkowymi IP cores Digilenta (nie wiem, czy próby te zakończą się sukcessem, ale przynajmniej będzie zrobiony wstęp do dyskusji w tym temacie. Ponieważ temat jest bardzo rozległy będę ten post pisał partiami. Podstawowym tutorialem do tego tematu będzie: https://reference.digilentinc.com/learn/programmable-logic/tutorials/pmod-ips/start Tutorial ten zakłada na wstępie, że dysponujemy hard-procesorem "Zynq" Xilinxa, lub soft-procesorem Microblaze, Nasz post dotyczy tej drugiej opcji, czyli użycia Microblaze'a z modułami Pmod. Ponieważ nie dysponujemy projektem Microblaze w Vivado powyższy tutorial zakłada, że stworzymu taki projekt korzystając z "przepisu" pod tym linkiem: Getting Started with the Vivado IP Integrator Jako pierwszą część zamieszczam projekt soft-CPU Microblaze w "Vivado 2018.2" (wewnątrz tego projektu jest katalog z wyeksportowanym projektem Microblaze do "Xilinx SDK 2018.2"). Teoretycznie zmieniając płytę (board) projektu w Vivado, oraz startując syntezę, implementację i generację bitstream, oraz eksportując projekt ponownie do SDK, możemy projekt przenieść dla innego zestawu FPGA. Patrz ten link: https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 W pliku "Micro4Pmod.zip" znajduje się projekt Vivado z Microblaze (i z wygenerowanym z niego projektem dla xilinx SDK). Na tym zakończę część pierwszą tego postu. W części drugiej (za jakiś czas opiszę moje próby dodania do projektu "Vivado IP Library" i uruchomienia "Pmod CAN". Pozdrawiam ---------------------------------------------------------------------- Przechodzimy do części drugiej tutoriala (2. Add the Digilent Library Repository): https://reference.digilentinc.com/learn/programmable-logic/tutorials/pmod-ips/start Najpierw pobieramy ze strony Githuba bibliotekę :Digilent Vivado Library 2018.2: https://github.com/Digilent/vivado-library/releases W naszym przypadku jest to plik: vivado-library-2018.2-1.zip Rozpakowujemy ten plik do łatwo dostępnego katalogu na dysku twardym komputera (u mnie jest to: E:\_Current\vivado-library-2018.2-1). Następnie otwieramy w Vivado nasz projekt z Microblaze. i klikamy we "flow navigator" opcję "IP Catalog" - otworzy się zakładka "IP Catalog" w oknie po prawej stronie. klikamy prawym klawiszem opcje "Add Repository" i w oknie wyboru katalogu podajemy katalog, gdzie rozpakowaliśmy bibliotekę Digilenta. Patrz obrazek: Nastepnie klikamy klawisz <Select> i óźniej potwierdzamy opcję importu "IP Cores" do modułów Pmod. Następnie klikamy we "Flow Navigator" opcję <Open Block design>, a gdy się otworzy wybieramy zakładkę "Boards". Patrz obrazek Następnie klikamy duży klawisz < + > w oknie diagramu i z listy wybieramy IP core dla interesującego nas modułu Pmod (u mnie to: PmodCan_v1_0): Moduł PmodCAN zostanie dodany do diagramu: Klikamy "Run Connection Automation" wybieramy checkbox "All conection automation" i zatwierdzamy klawiszem "OK". Następnie w oknie diagramu lączymy linię 'ext_spi_clk" z "s_axi_clk". Patrz obrazek: Po tym punkcie utknąłem bo nie wiem jak prawidłowo połączyć linie: "SPI_innterrupt" oraz "GPO_innterrupt" modułu "PmodCAN" z resztą układu - zapewne trzeba dodać jakiś kontroler przerwań i połączyć to z resztą układu. Może ktoś pomoże ? Ja już muszę dzisiaj kończyć, wrócę do tematu w najbliższej wolnej chwili. Pozdrawiam Micro4Pmod.zip
  40. 3 punkty
    Wykładowca miał rację. Układ jest teoretycznie symetryczny, ale ma dwa stany stabilne i któryś musi wybrać. Po włączeniu zasilania, mimo dobrej baterii napięcie (i prąd) nie pojawia się od razu. Gdybyś obejrzał to pod mikroskopem (no dobra, na ekranie oscyloskopu) to zauważysz, że narastanie zachodzi z pewną skończoną prędkością. Całość ma bowiem jakąś pojemność i indukcyjność (przewody, elementy półprzewodnikowe, oporniki, wszystko). Są to nieduże wartości, ale jednak niezerowe a to opóźnia stromość zbocza i to jest właśnie czas w którym następuje podjęcie "decyzji". Ponieważ masz tu silne sprzężenie zwrotne dodatnie, to każda niesymetria jest powielana do ostatecznego zwycięstwa którejś strony. A w tak prostym układzie każdy element się liczy. Na poziomie zasilania rzędu 0.5V, gdy tranzystory są jeszcze oba wyłączone, baza każdego z nich jest zasilana przez "przeciwną" diodę LED i jej opornik. Mamy więc aż cztery elementy wpływające na prąd bazy: dwa rezystory, LED i złącze BE tranzystora. Do tego dochodzi wzmocnienie samego tranzystora czyli to jak dobrze "spożytkuje" on prąd swojej bazy na prąd kolektora. Ponieważ nie jest możliwe, by ten zestaw był identyczny w obu gałęziach, któryś umożliwia przepływ większego prądu i ten tranazystor delikatnie zaczyna przewodzić lepiej. A wystarczy 0.1% różnicy gdzieś przy zasilaniu 1 czy 2V by dany tranzystor "popuścił" trochę prądu kolektora. Ten prąd "wysysa" dopływający z góry prąd z gałęzi LED i przydusza do masy (obniża) napięcie kolektora. To z kolei zmniejsza prąd bazy konkurenta i dalszy proces jest lawinowy - to właśnie jest to dodatnie sprzężenie zwrotne. Gdy raz układ wejdzie w tunel niesymetrycznego rozpływu prądów, nie ma odwrotu, musi zapaść się w lewy lub prawy dołek. Nie wiadomo który element jest kluczowy. Typowe oporniki mają tolerancje 1-5%, diody LED w ogóle nie są określane w ten sposób - tam raczej bazujesz na ogólnym wykresie prądu od napięcia, ale nikt nie podaje dokładnych napięć przewodzenia i zachowania się LEDa przy prądach np. 1uA, bo i tak sensownie świecić zaczyna dopiero przy setkach uA. Proces produkcji tranzystorów także ma jakieś rozrzuty: po pierwsze powstały z dwóch różnych kawałków monokryształu krzemu, po drugie domieszkowanie warstw może zachodzić różnie w różnych miejscach płytki, do tego dochodzi cięcie, bonding czyli lutowanie doprowadzeń, różnice w położeniui na elemencie nośnym, Twój montaż czyli kabelki, połączenia, fizyczna geometria układu, itd itp. Gdybyś chciał się dowiedzieć co determinuje zachowanie układu, musiałbyś kolejno zamieniać parami elementy z gałęzi tak jak sugerował prowadzący, ale nie tylko tranzystory - to dotyczy wszystkiego. Niestety być może jest tak, że to dany zestaw jest kluczowy bo tu liczy się suma parametrów jego elementów. Zamienianie części w łańcuszku zasilania bazy w końcu doprowadzi do odwrócenia, ale nie musi to być czarno-białe i możesz mieć sytuację, w której druga strona zacznie przeważać, ale nie w 100% przypadków. Z punktu widzenia aplikacji - o ile nie robisz generatora szumu - układ zachowujący się losowo jest słaby. A przecież problem stanu początkowego dotyczy wszystkich układów dwustanowych. Przecież z takich 2- lub 4-tranzystorowych modułów zrobione są np. statyczne pamięci RAM czy przerzutniki będące elementami liczników, timerów czy rejestrów mikroprocesorów. Po włączeniu zasilania ich stan jest przypadkowy, ale o ile w pamięci śmieci nie przeszkadzają - program pobierany i wykonywany np. z FLASHa może po starcie RAM wyzerować, o tyle stan wewnętrzny procesora nie może być nieznany bo wszystko się posypie. Dlatego właśnie tak ważna jest generacja sygnału RESET. Wszystkie przerzutniki mają dodatkowe wejście zerowania wymuszające przejście do jednego, określonego stanu. Kiedyś musiałeś sam zadbać, by wygenerować sygnał zerowania procesora po włączeniu. Dziś takie układy nadzoru są wbudowywane w kostki i to własnie te bloczki produkują RESET zaraz po włączeniu Vcc. Dodatkowa nóżka umożliwia restart systemu na żądanie, ale podstawowe wyczyszczenie stanu wszystkich przerzutników i poprawny start programu od adresu zero odbywa się na żądanie jakiegoś niepozornego modułu ukrytego wewnątrz struktury mikrokontrolera. Wykrywa on narastanie zasilania i jego stabilizację na określonym poziomie i wysyła wszystkim wokół impuls/sygnał RESET. Po jego zakończeniu (trwa to zwykle kilka-naście-dziesiąt milisekund) procesor jest w stanie początkowym i może zacząć przewidywalne działanie. Ty możesz to samo wbudować w swój przerzutnik i cieszyć się jego wymuszonym determinizmem, bo to co masz teraz to czysta losowość. I nie polega ona na tym, że po włączeniu masz różne stany ale na tym, że budując układ nie jesteś w stanie przewidzieć która gałąź zwycięży. Zakładając, że konstruujesz np. licznik i chcesz 4 takie przerzutniki to chciałbyś pewnie, by po włączniu licznik był wyzerowany a tego nie zagwarantujesz wprost. Możesz żmudnie dobierać elementy co sprowadza się do wbudowania pewnej niesymetrii (która jest szkodliwa), ale możesz po prostu doprowadzić sygnał RESET z przycisku albo z układu RC i zerować licznik automatycznie bez oglądania się na to który przerzutnik woli który stan startowy.
  41. 3 punkty
    Jestem tutaj od samych początków (jeszcze pod inną domeną), wróciłem po kilkuletniej przerwie i trochę łezka się w oku kręci na wspomnienie "tamtych dni", tych dyskusji o tym, czy dany projekt jest robotem i powinien być omawiany na forum, czy nie Technologia jednak poszła naprzód i dzisiaj coraz ciężej jest rozróżnić robotykę od zagadnień IoT czy automatyki domowej, a tematy programowania mikrokontrolerów i podstaw elektroniki zawsze były, są i będą integralną częścią tego wszystkiego. Cieszę się, że Forbot idzie z duchem czasu, a efektem tego jest stały przypływ ludzi zafascynowanych robotyką, elektroniką i programowaniem. Czapki z głów oraz gratulacje dla Trekera i całej aktywnej społeczności Forbota - oby tak dalej
  42. 3 punkty
    Jak dodać pakiet Pisanie o bootloader-ach mogło wydać się już nieco nudne, wracam więc do głównego wątku. Jak wspominałem wcześniej core-image-minimal tworzy minimalny obraz systemu. Wbrew pozorom to często dobry punkt wyjścia do tworzenia własnego projektu. Wypadałoby jednak coś to tego minimum dodać. Można to zrobić na wiele sposobów, najprościej jest zmienić plik conf/local.conf. Jak pamiętamy są w nim główne ustawienia z których korzysta yocto. Do dodawania pakietów służy polecenie: CORE_IMAGE_EXTRA_INSTALL += "bcm2835-dev rpi-gpio wiringpi" Czyli dodajemy do zmiennej CORE_IMAGE_EXTRA_INSTALL oddzielone spacjami nazwy potrzebnych nam pakietów. Yocto zadba o wszystkie zależności, więc dodając bibliotekę rpi-gpio dla pythona automatycznie włączyłem wsparcie dla tego języka. Yocto doda wybrane pakiety do obrazu, przygotuje również paczki z tymi pakietami, więc jeśli ktoś chciałby używać takiego systemu w sposób typowy dla zwykłych dystrybucji może sobie powiedzmy wiringpi pobrać i doinstalować. Muszę się jednak przyznać do pewnego problemu, który obszedłem niezbyt elegancko. Wcześniej miałem ambicje żeby wszystko kompilować w trybie 64-bitowym. Niestety okazało się, że moduły specyficzne dla Raspberry jak np. GPIO nie radzą sobie z tym najlepiej. Ostatecznie więc zmieniłem definicję maszyny i używam: MACHINE = "raspberrypi3" Pewnie można byłoby zostać przy raspberry3-64, ale tak było najłatwiej. Za to nie tylko gpio zaczęło działać, ale nawet framebuffer wystartował w pełni: Obraz z dodanymi pakietami jest trochę większy - zajmuje już 76MB, jednak jest znacznie ciekawszy. Mamy na nim bibliotekę wiringPi, python-a 2, oraz RPi.GPIO - można więc uruchamiać przykłady z kursu Raspberry Pi (https://forbot.pl/blog/kurs-raspberry-pi-podstawy-pythona-gpio-id26099). Pakiety które chcemy zainstalować znajdziemy w odpowiednich warstwach, te które dodawałem są w meta-raspberrypi, a dokładniej meta-raspberrypi/recipes-devtools: http://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/tree/recipes-devtools W ten sposób możemy dodawać gotowe pakiety do systemu, aż uzyskamy oczekiwaną konfigurację. Możemy również tworzyć własne pakiety (i dołączać do obrazu) - w ten sposób yocto przygotuje nam gotową dystrybucję zgodną z oczekiwaniami naszego projektu. Dla osób lubiących interfejsy graficzne dostępne jest narzędzie o nazwie Toaster: https://www.yoctoproject.org/software-item/toaster/ Pozwala ono na wykonywanie opisywanych czynności za pomocą interfejsu opartego o przeglądarkę. Ja nie jestem zwolennikiem takich rozwiązań, ale na pewno łatwiej jest tak wybierać pakiety:
  43. 3 punkty
    Cześć dzami97. Rozczytałem dokumentacje i okazuje się że HAL domyślnie zaraz po resecie ustawia taktowanie szyn AHB i APB z wewnętrznego oscylatora HSI którego częstotliwość wynosi 8MHZ. Żeby wycisnąć 64MHZ należy skonfigurować prescaler HSI na 2 i mnożnik pętli PLL na 16 dzięki czemu uzyska się częstotliwość 64MHZ. Poniżej wklejam kod konfiguracji: Ostrzegam, że w STM32F1 jestem początkujący i sama konfiguracja może nie być doskonała, ale ogólnie wszystko działa . RCC_OscInitTypeDef osc; osc.OscillatorType = RCC_OSCILLATORTYPE_HSI; osc.HSEState = RCC_HSE_OFF; osc.HSIState = RCC_HSI_ON; osc.HSICalibrationValue = 16; osc.PLL.PLLState = RCC_PLLSOURCE_HSI_DIV2; osc.PLL.PLLMUL = RCC_PLL_MUL16; HAL_RCC_OscConfig(&osc); RCC_ClkInitTypeDef clk; clk.ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2; clk.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; clk.AHBCLKDivider = RCC_SYSCLK_DIV1; clk.APB1CLKDivider = RCC_HCLK_DIV2; clk.APB2CLKDivider = RCC_HCLK_DIV1; HAL_RCC_ClockConfig(&clk, FLASH_LATENCY_2); SystemCoreClockUpdate(); HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq() / 1000); HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
  44. 3 punkty
    1. Nie ma znaczenia z czego i czy z tego samego są elektrody kondensatora. Dla nas jako dla użytkowników ważne jest, czy kondensator ma określoną przez producenta biegunowość czy nie. Jeżeli ma - wszystko jedno z jakiego powodu - to musisz go używać zgodnie z zaleceniami. W układzie musisz go włączyć tak by polaryzacja napięcia na nim była zawsze poprawna. Jeżeli ją odwrócisz np. poprzez nieprawidłowy montaż lub błąd w projekcie może się zdarzyć wiele rzeczy. Od raczej niegroźnych: spadek pojemności i/lub trwałości do poważniejszych: przepływ prądu stałego, podgrzewanie aż do zagotowania elektrolitu i wybuchu, zwarcie i uszkodzenie innych elementów itd. 2. Liczą się trzy rzeczy: powierzchnia elektrod, ich odległość i rodzaj izolatora - w szczególności jego stała dielektryczna. W każdym kondensatorze korzystamy ze wszystkich tych cech. Niestety jak to zwykle bywa nic nie jest za darmo. Jeśli zwiększysz wielkość okładzin, rośnie pojemność ale kosztem wielkości i masy. Rosną też pasożytnicze: rezystancja i indukcyjność a tego przecież nie chcemy. Zmniejszając grubość dielektryka też rośnie pojemność, ale spada napięcie przebicia. W tej samej wielkości kubeczku dostaniesz kondensator np. 100uF/10V albo 22uF/35V albo 10uF/63V. No i sam izolator - te z większymi stałymi są coraz droższe i bardziej "humorzaste" - bardziej zależą od temperatury i nawet od napięcia. Dlatego np. małe kondensatory ceramiczne o względenie dużych pojemnościach nie nadają się do pewnych układów np. audio czy pomiarowych, bo ich pojemność zależy od przyłożonego napięcia(!) co wprowadza zniekształcenia sygnału oraz (bardzo) od temperatury co uniemożliwia robienie precyzyjnych obwodów np. filtrów czy czasowych. W popularnych "elektrolitach" jedną z elektrod jest aluminiowa blaszka a dielektrykiem bardzo cienki tlenek na jej powierzchni. Żeby ją zwiększyć, blaszkę nadtrawia się wstępnie kwasem, który robi mnóstwo mikrogórek i dołków i z 2cm² robi 10x więcej. Za to tlenek aluminium jest nieodporny na przepływ prądu stałego, który zachodzi po przyłożeniu odwrotnego napięcia. To dlatego elektrolity mają "plus" albo "minus" narysowany na obudowie a próby zmiany tej polaryzacji prawie na pewno spowodują zniszczenie kondensatora (a czasem - przy wystarczająco dużym napięciu i prądzie - także i najbliższej okolicy).
  45. 3 punkty
    Piszę wolno więc przy tak burzliwej dyskusji moje posty szybko się dezaktualizują, ale: Babol jest, bo każde przerwanie z którego nie wyjdziesz poprawnie przez return odkłada na stosie adres powrotu. Tak więc stos rośnie. A teraz próbujesz nas przekonać, że wszystko jest OK bo nie zauważyłeś problemów? Mogę zrozumieć taki punkt widzenia: nie widzisz nic złego w działaniu - to problem rozwiązany ale zauważ, że to tylko oznacza, że nie zauważasz kłopotów. To nie to samo. Jeśli procesor po którymś przyciśnięciu tak zniszczy RAM, że np. przejdzie przez własny wektor RESETu - sprawa załatwiona. Jeśli nikt z was nie tego nie zauważył, spoko, jesteście zadowoleni. Ale my staramy się dojść przyczyn Twoich problemów, bo naszym zdaniem je masz. Jeśli wg Twojej oceny tak nie jest bo efekty na to nie wskazują, rozchodzimy się każdy z jakimś tam samozadowoleniem. Ja widzę co robisz źle, Ty nie uznajesz tego za problem. Pisałem o braku determinizmu działania takich rzeczy i to jest tu najważniejsze. To także odróżnia - w przypadkach niedookreślonych - jedną sztukę procesora od drugiego. Opadający wskaźnik stosu będzie robił to w przypadkowych momentach i niszczył przypadkowe (w sensie akurat wykonywanych przez program rzeczy) lokacje. Rejestry procesora to też RAM więc nawet jeśli jakaś pętla jest sterowana licznikiem zorganizowanym przez kompilator w rejestrze, jej licznik lub cokolwiek innego także mogą zostać zniszczone. Rozwiązanie sugerowane przez Elvisa jest rozpaczliwe, ale w tej sytuacji powinno pomóc. Pod warunkiem, że nasza diagnoza i model błędu są poprawne... Przemyśl to i wymyśl strukturę tego kodu tak, by wszelkie mechanizmy wykorzystywać zgodnie z ich naturą - to może być naprawdę fajne ćwiczenie. Jedyną rzeczą nieprzerywalną w tym urządzeniu jest funkcja wysyłania strumienia danych do diodek. Tego nie może przerwać nawet obsługa odbiornika IR i to powinna być sekcja krytyczna. Przy dużej liczbie diodek to może stanowić poważny problem bo niektóre kody IR mogą być nieodbierane. Trzeba się z tym pogodzić ale zauważ, że wysyłanie danych może być bardzo rzadkie - tylko wtedy gdy zmienia się stan łańcucha. To trochę ratuje, ale nie znika problemu zupełnie. Wszystko inne, łącznie z organizacją programu, liczeniem numeru efektu czy samą jego generacją może być przerywane. Nawet obsługa przycisku (debouncing) powinna być robiona w jakimś okresowym przerwaniu od timera a nie za pomocą kondensatorów - tak robi się w przedszkolu. Mając w systemie zdarzenie typu "wykryto wciśnięcie" możesz go obsłużyć kiedy chcesz. Zwłoka nawet kilkudziesięciu ms niczego nie zmienia i jest niezauważalna. A co procesor ma innego do roboty? Jeżeli dopuścisz obsługę przerwań w czasie wysyłania strumienia do LED, trzeba będzie pogodzić się z faktem chwilowego uszkadzania zawartości łańcucha, ale tylko podczas manipulacji na pilocie a to i tak zmienia używany efekt. Same efekty nie powinny być pisane jak jedna wielka pętla zajmująca procesorowi wiele sekund - to także błąd w założeniach. Gdybyś zrobił jakiś systemowy timer np odliczający tick=50 czy 100ms to miałbyś podstawę czasu. Bazując na takich interwałach możesz zaprojektować efekty, które zmieniają stan łańcucha co taki czas (to chyba wystarczająco często) jednocześnie umożliwiając procesorowi robienie wielu rzeczy na raz. Także zatrzymanie i zmianę efektu w dowolnej chwili, bo proces nadzorujący przycisk i zmiany wykonywany jest równolegle ze wszystkim innym. Trzeba tylko usiąść i zastanowić się jak te wszystkie rzeczy na raz pogodzić. Chociaż pewnie nie masz wykształcenia informatycznego i doświadczenia w pisaniu kodu wielo- i współbieżnego, to nie jest trudne a jak już raz przez to przejdziesz, Twoje programy będą od tej pory zupełnie inne. Sam się zdziwisz. Hm, w sumie to nie wiem, czy warto dalej to o tym pisać. To kwestia podejścia do swojego hobby w ogóle a do programowania w szczególności. Moim zdaniem tu nie chodzi o "spryt" czy efekty końcowe a o dochodzenie do pewnego rodzaju mistrzostwa w samym procesie powstawania produktu. Jak w kenjutsu, rowerowaniu czy nawet.. elektronice. Nigdy nie jesteś najlepszy, zawsze jest coś w Tobie do poprawienia a gdy się zatrzymasz w rozwoju lub uznasz, że osiągnąłeś efekt - przegrałeś (choćby sam ze sobą). Rozumiem, że nie każdy tak to widzi.
  46. 3 punkty
    Hm, stare Pentium IV z radiatorem wygląda dość efektownie. W zasadzie mogłoby nawet nic nie robić tylko stać na półce.. A tak naprawdę to każdy scalak, nawet zamknięty w obudowie TQFP100 (ATmega1280) robi na laikach mniej więcej podobne - czyli żadne - wrażenie. Przecież w prezentach chodzi o samą pamięć, poświęcony czas (niektórzy umieją to docenić, inni nie) i przyjemność (tak robienia/kupowania jak i otrzymywania). Zrobisz na niej wrażenie jeśli będziesz schludnie wyglądał, ładnie pachniał, poprawnie mówił i umiał słuchać - kolejność przypadkowa. Nie obiecuj sobie za wiele po typie wybranego procesora, nie oczekuj wybuchu radości ani nawet krztyny zainteresowania szczegółami projektu PCB. Jeżeli doceni Twój prezent i Twoje zaangażowanie, zobaczysz to inny sposób. Nie próbuj tłumaczyć "jak to działa" tylko przynieś kwiatek, zaproś na kawę + ciacho, opowiedz o ostatnio przeczytanej dobrej książce i zapytaj co jej się ostatnio śniło fajnego - to działa na pewno. Musisz ją zainteresować sobą i pokazać, że jesteś gościem wartym poświęcania mu czasu. Reszta to opakowanie. No i nie będziesz chyba umawiał się z jej ojcem-idiotą - sądząc po opisie. Mam nadzieję, że jednak krzywdzącym i niesłusznym, bo inaczej miałbyś strasznego pecha już na starcie..
  47. 3 punkty
    Od roku prowadzę w Katolickim Gimnazjum w Markach zajęcia z robotyki i chciałbym się pochwalić pracami moich uczniów. W ubiegłym roku rozpoczynaliśmy prace budując podwozia z paneli ze sterownika pieca. Teraz jedno z nich służy do prób sterowania pilotem na podczerwień. Kiedy zamawiałem banner w jednej z firm reklamowych zobaczyłem pod murkiem trochę ścinków spienionego pcv. Poprosiłem o możliwość zabrania i od tamtej pory mamy stały napływ materiału. Uczniowie są bardzo kreatywni. Uznali, że skoro nie mamy nieskończonej ilości modułów, czujników należy stworzyć takie podwozia-laboratoria, które umożliwią ich szybką wymianę. To podwozie ze spienionego pcv ma szczycie uchwyt wykonany z fragmentów dwóch wykałaczek. Dzięki temu serwomechanizm łatwo się zakłada i zdejmuje. Podobnie jak czujnik ultradźwiękowy. W podbrzuszu podwozia gniazda podłączenia serwomechanizmu i czujnika ultradźwiękowego. Również specjalna kieszeń na upchanie zbyt długiego kabla. Robot jeździ po równym więc ciasno wciśnięty kabelek nie wypada. Drugie podwozie z takiego samego materiału wozi na grzbiecie samodzielnie wykonane arduino na płytce uniwersalnej PDU-19 oraz mostek h na płytce PDU-17. Chodziło o naukę czytani schematów i lutowania. Podwozie ma z przodu zakładaną klapkę na wcisk na rożnego rodzaju czujniki, płytki stykowe itp. W założeniu mają być klapki z serwomechanizmem i HC-SRO4, włącznikami krańcowymi (zresztą taki jest przylutowany jako reset), czujnikami na podczerwień czy takimi, które uczynią z niego linefollower. Pod "płytą główną", umieszczoną na plastikowych dystansach, zostało miejsce na dodatkowe ewentualne elementy. Starsi uczniowie nie chcą już budować pojazdów jeżdżących (na razie) tylko pracują nad rozbudowanym systemem inteligentnego domu. Właśnie kończą tworzyć makietę i kompletujemy potrzebne elementy. Dom "powiadomi" o intruzie, zalaniu, pożarze, a wszystko sms-em dzięki staremu telefonowi komórkowemu. Tak wyglądają prawie wszystkie nasze podwozia Mają jedno podstawowe zadanie - są pewnego rodzaju jeżdżącymi laboratoriami, które służą do testowania nowych rozwiązań. Gimnazjalista potrafi. O początkach naszej działalności pisałem na forum tutaj >>
  48. 3 punkty
    Wstawiam zatem tajne zdjęcia mojego skomplikowanego mechanizmu pozwalającego zamocować Proxxona do zwykłego (lepszego?) statywu do wiertarki. Zatem, należy wyprodukować takie oto coś: Jak widać, jest to tuleja, która z zewnątrz ma 43mm (mocowanie do zwykłej wiertarki), a wewnątrz powinien wchodzić pasownie uchwyt Proxxona (który deklaruje 20mm). Tuleję należy rozciąć wzdłuż. Kołnierzyk służy tylko i wyłącznie do tego, aby wygodniej wkładać tuleję do statywu. Ta tulejka jest akurat z aluminium, ale przypuszczam że z tworzywa albo ze stali będzie się sprawdzała równie dobrze. Tutaj oto możemy zauważyć, jak bardzo pomocny jest ergonomiczny kołnierzyk, dzięki któremu tulejka nie pitła na dół i mogłem na przykład zrobić powyższe zdjęcie. Po włożeniu Proxxona do tulejki i zaciśnięciu uchwytu na statywie, powinna nam się delikatnie ścisnąć również tulejka, a co za tym idzie unieruchomić Proxxona. Z góry uprzedzam, że z tego co mierzyłem otwór wewnętrzny aluminiowej tulejki zmniejszył się o jakieś 0,3mm. Jeśli otwór jest zrobiony z dobrą tolerancją, to jest to całkowicie wystarczające. Teraz można już rzucać statywem w teściową nie martwiąc się, że szlifierka wypadnie. Jeśli ktoś pomyślał sobie "co za debil, przecież jakby tulejka była krótsza to miałby dostęp do uchwytu wiertarskiego i nie musiał wyjmować szlifierki przy każdej zmianie narzędzia" to może sobie w nagrodę kupić piwo, gdyż jest to prawda. Jednakże, ponieważ pierwszą tulejkę zepsułem, obie robiłem późnym wieczorem, są wakacje oraz jestem leniem, to nie mam zamiaru poprawiać tego błędu.
  49. 2 punkty
    Cześć, niedawno był wątek bardzo podobny i użytkownik forum chciał kupić jako swój pierwszy multimetr - multimetr wzorcowy Brynera za 2K PLN (taki jaki jest używany w mojej firmie do sprawdzania dokładności innych mierników). Watek według mnie trochę podobny. Ja osobiście używam Bitscope mini (BS10) i nie zamienił bym go na Hantek'a czy Rigol'a z 2 do 3 K PLN. Powody: 1) Jest dużo bardziej uniwersalnym narzędziem pomiarowym od taniego oscyloskopu stacjonarnego (takiego z 2K PLN) 2) Zajmuje dużo mniej miejsca 3) Software ma bardzo wymyślne funkcje i jest bardzo często aktualizowany 4) Wyświetlacz jest dużo większy 5) Jest tańszy Przedtem używałem przez 2 lata Bitscope micro: http://bitscope.com/product/BS05/ i byłem też zadowolony, ale od czasu gdy zacząłem zajmować si,ę układami FPGA to pasmo 20 MHz przestało mi wystarczać. W firmie dla której robiłem zlecenie przez kilka miesięcy używałem Hantek'a za właśnie gdzieś około 2 K PLN. Gdybym miał wybór wybrałbym Bistcope Mini ze względu na dużo większy zakres funkcjonalności i większy wyświetlacz. W pracy mam oscyloskop za około 20 K PLN i analizator widma za około 40 K PLN i razem mają zbliżoną do niego BS10 funkcjonalność (oprócz oczywiście od szerszego pasma częstotliwości). Oczywiście masz pełne prawo mieć odmienne zdanie i właśnie po to jest forum. Ja też kiedyś uważałem, że osobny oscyloskop jest lepszy, niestety praktyka tego nie potwierdziła. Stacjonarnego oscyloskopu nie wsadzisz do niedużego plecaka, czy torby, zajmuje sporo miejsca a często dostęp do zabudowanych urządzeń jest utrudniony (np. na jakichś wyjazdach serwisowych). Funkcje software'u są bardzo rozbudowane co często bardzo się przydaje i dość często aktualizowane. Nie obraź się, ale nie uważam, żeby zakup oscyloskopu analogowego miał większy sens niż cyfrowego Pozdrawiam
  50. 2 punkty
    OK, nie spodziewam się, żeby dużo było "wczesnych sieciowców" będących równocześnie kolejarzami. To raczej zupełnie inne dziedziny. (patrz zresztą moja wcześniejsza uwaga o ekonomice). Ale owszem, używanie "na pałę" paskudnych, kalekich makaronizmów jest zaśmiecaniem własnego języka. I nie wydaje mi się, żeby była taka znowu korzystna. Jeśli będziesz miał projekt w innym języku niż angielski, i tak będziesz musiał szukać co oznacza Wiederstand, Ellenállás, czy Vastus. Czyli oszczędność jest dość złudna. Swoją drogą, dlaczego nie kupujesz w sklepie dwu kilogram cukru? Brzmi dziwnie, prawda? A z Warszawy do Łodzi nie jest "trochę ponad 100 kilometr".
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...