Leoneq

Jak widzę, brakuje Ci pinMode(LED_PIN, OUTPUT); w setupie.

Spróbuj te funkcje zdeklarować przed funkcją setup - przenieś je na górę, i powinno być ok.

Takie proste jeździdełko a cieszy

Kolejne dwa projekty. Prosiłbym o nie łączenie kodów - i pytanie, czy poprzedni kod można "rozłączyć"? Wcześniej zapomniałem o tym, nie zwróciłem uwagi i dopiero teraz zauważyłem...

Silniki obecnie są zwykłe z przekładniami xd W artykule chyba nawet link jest do nich. Musiałbym chyba sam silnik wymienić, albo w przekładnię zajrzeć. Jak znajdę chwilę to jeszcze się pobawię z tymi napędami, najwyżej wymienię na te żółte 48:1.

Linear advance to taka technika jakby, która koryguje przyspieszenie i zwolnienie karetki (na początku kreska filamentu z dyszy jest cieńsza, na końcu grubsza). Funkcja ta podaje na początku zatem więcej filamentu, na końcu odrobinę mniej. Każda drukarka ją może mieć, która ma marlina.

Właśnie problem jest taki, że jeden silnik jest normalny, a drugi "załącza się" od pewnego napięcia - niżej się nie załączy. Próbowałem różne progi ustawiać, skutkowało to zbyt nagłymi ruchami robota.

W planach mam zrobić "ultimate useless box" - z wyświetlaczem, drugim serwem na klapkę, a nawet napędem do uciekania. Ale to bardzo odległe plany.

Aż tak mi sie nie nudzi xd Chociaż warto spróbować. Praktyki z 555 nigdy nie za dużo.

Dziękuję ^^ Wiem że masa powinna być na górze, nie mam tylko co dać na górę - najwyżej sztucznie dociążyć, nie wiem czy to coś da. Filmik postaram się wrzucić pod wieczór, jak internet będzie odrobinę szybszy. ------------------------------------------------------------------------- edit: Jest i filmik pokazujący działanie robota. Wiem że dużo nie potrafi, ale bardzo satysfakcjonujące jest jak robot w końcu stoi, a nawet można go lekko szturchnąć - po całym tygodniu kodowania i naprawiania po upadkach. Jak się nie zaliczy na rabat, to trudno, i tak już mi dużo pomógł

Witam. Ten projekt, mimo że wygląda na dość prosty, musiałem go bardzo rozpracować - jest to praca na "wprowadzenie do wykonywania zawodu", czyli mechatronikę. Założenia były takie: zrobić projekt, który widać że działa, jest stosunkowo prosty w konstrukcji. Wybór padł na useless box, czyli bezużyteczne pudełko. Bezużyteczne pudełka nie robią nic pożytecznego - jeżeli ktoś im przeszkodzi w byciu przyciskiem do papieru, albo kurzołapem - same się wyłączą. Tak więc, uznałem że optymalnie będzie to zrealizować na timerze 555 i serwie modelarskim. Zacząłem od sprawdzenia datasheeta serwa. Gdzieś przeczytałem, że serwa steruje się nie przez PWM a PPM (pulse position modulation). Nie miałem czasu badać tego aż tak, więc przyjąłem po prostu informacje z datasheeta. Kąt nachylenia od 0 do 180 stopni, i moment 1,8kg/cm powinien starczyć z dużym zapasem. Zgodnie z tym diagramem, trzeba wygenerować sygnał PWM o częstotliwości 50Hz - jedna ramka ma długość 20ms. Z forbotowego kursu elektroniki wiemy, że takie coś można wygenerować timerem w trybie astabilnym. Tak wygląda schemat żywcem wzięty z datasheeta 555: Działanie tego układu jest następujące: po podłączeniu zasilania kondensator C ładuje się - przez co na wyjściu jest stan wysoki. Ładuje się on przez rezystory Ra i Rb podłączone do zasilania. Kiedy kondensator naładuje się do 2/3 napięcia zasilania, wyjście jest ustawiane na stan niski, a kondensator się rozładowuje przez rezystor Rb podłączony do pinu “discharge”. Po rozładowaniu do 1/3 napięcia zasilania, wyjście znowu jest ustawiane na stan wysoki, a kondensator się ładuje - cykl się powtarza. Czas wysoki będzie zatem zależny od Ra i Rb, a niski od Rb. Zgodnie z pierwszym diagramem, aby wychylić serwo o -90 stopni wypełnienie musi wynosić 1ms. Aby orczyk się obrócił do +90 stopni, sygnał musi mieć wypełnienie 2ms. Wykonałem wstępne obliczenia - do powyższego schematu zostały dołączone wzory: Rezystancja niestety wychodziła ujemna. Wniosek prosty - ten układ nie nadaje się do naszego zastosowania, a przynajmniej w takiej formie. Tak jak w forbotowym przykładzie z kursu elektroniki, dodałem diodę równolegle z Rb. Od teraz Ra odpowiadał tylko za ładowanie kondensatora, a Rb tylko za rozładowywanie. Dlatego we wzorze na th mogę pominąć Rb: Jak widać, obliczyłem 3 rezystory - wspólny, rozładowujący, i 2 ładujące. Pierwszy spowoduje schowanie ramienia, drugi spowoduje jego wychylenie. Wszystko powinien rozjaśnić schemat: Nie miałem akurat żadnego akumulatora, więc źródło zasilania stanowią 4 paluszki AAA. Kondensator C1 filtruje zasilanie, i tam gdzie się dało umieściłem konektory. Płytkę zlutowałem na protoboardzie: Obudowę wydrukowałem na drukarce 3D, białym PLA od Spectrum. "Wnętrzności" pudełka wydrukowałem kolorem czerwonym. Po złożeniu, całość wyglądała tak: Wykorzystałem tutaj sprężynę z długopisu, spinacz jako oś dla klapki, całość skręciłem różnymi śrubkami. Przyszedł czas na odpalenie, a tu niespodzianka: nie działa (wow). Znaczy - działa, ale ramię ma za mało mocy do przełączenia dźwigni. Orczyk był prawidłowo przykręcony, okazało się że wypełnienie musiało być złe. Szybkie rozkręcanie, i patrzymy w oscyloskop: Eksperymentalnie dobrałem nowe wartości rezystora. Potencjometr szeregowo połączyłem z Rb, i udało się dobrać dobrą rezystancję. Po zmierzeniu miernikiem, okazało się że należy wlutować rezystor 2.7kΩ. Tak też zrobiłem - a bezużyteczne pudełko w końcu mogło się bronić przed napastliwą działalnością człowieka. Założenia projektu zostały spełnione, a projekt zaakceptowany. Projekt można uznać za zakończony sukcesem. Linki: datasheet SG90: http://www.ee.ic.ac.uk/pcheung/teaching/DE1_EE/stores/sg90_datasheet.pdf datasheet NE555: http://www.ti.com/lit/ds/symlink/ne555.pdf

Witam. Chcę pokazać swoją kolejną konstrukcję, zapoczątkowaną w listopadzie zeszłego roku. Jest nim robot balansujący, który miał jedno specjalne zadanie - pomóc mi zrozumieć działanie regulatorów. Na początku myślałem "wystarczy jechać do przodu/do tyłu jak się robot przewraca" - byłem w ogromnym błędzie. Tak wygląda finalna wersja robota: Tak więc, na początku obmyśliłem konstrukcję robota. Pod ręką miałem zmodyfikowane serwa SG90 do wykonywania pełnych obrotów - przykleiłem je do akumulatora, tam gdzie się dało dokleiłem klejem na gorąco Pro Mini, żyroskop i akcelerometr MPU6050, moduł z TP4056, wyłącznik i czujnik odbiciowy, jako prosty przełącznik do debugowania. Wszystko polutowałem, koła wydrukowałem na drukarce 3D - za "opony" posłużyły tutaj gumki recepturki. Kod był prosty: odczytujemy aktualny kąt - jeżeli jest dodatni, jedziemy do przodu, jeżeli jest ujemny - do tyłu, a kiedy robot jest pionowy - wyłączamy silniki. Jak można się domyślać (ja się nie domyśliłem), robot nigdy nie osiągnął pozycji stabilnej. Zacząłem czytać projekty podobnych robotów. Dużo z nich wywnioskowałem. Przede wszystkim - kilka faktów o naturze robotów balansujących. Są one bardzo dobrym przykładem odwrotnego wahadła - tak samo działa np. balansowanie kija na palcu. Tam, gdzie kij upada - tam dajemy palec, zapobiegamy upadnięciu. Jako że potrafimy kojarzyć kilka zmysłów, i analizować to co z nich odbieramy, bez problemu dobieramy prędkość palca. Brak regulatora (tak jak było z robotem) skutkowałby tym, że palec przesuwalibyśmy z maksymalną prędkością w te i we wte - kij by się przewrócił. Robotowi zatem brakowało takiego regulatora, który by regulował prędkość silników. Jako, że serwa nie mogłem już regulować, konstrukcję zmieniłem: wykorzystałem silniki z Botlandu, z przodu dałem akumulator z Nokii z logiką. Z tyłu - mniejszy akumulator Li-ion z TP4056, i przetwornicą step-up, dla silników. Wydrukowałem kolejne koła, tym razem "opony" są z TPU: Zmiana konstrukcji przyniosła jeszcze jedną, ważną zmianę. Dlaczego kij nam łatwiej balansować od długopisu? Z moich "doświadczeń", wywnioskowałem że im kij jest dłuższy, tym jego drugi koniec ma dłuższą drogę do przebycia. Daje nam to więcej czasu na zbalansowanie go. Poprzedni robot był krótki - ok. 30mm, co dawało bardzo mały czas na dojechanie na miejsce. (bardzo chciałbym dać obliczenia, ale nie mam pojęcia o momencie czy prędkości silników). Kod lekko zmieniłem, dodałem obsługę mostka H. Zaimplementowałem regulator PID - proporcjonalno-całkująco-różniczkujący, co (na razie) nic mi nie mówi. Jak przeczytałem, jest to jeden z najpopularniejszych regulatorów w robotyce. Nawet po przeczytaniu tego artykułu, dalej za dużo mi się nie rozjaśniło - brakuje mi wiedzy. Dlatego zacząłem się "bawić", eksperymentując z różnymi wartościami poszczególnych członów. Robot mimo wszystko ZA NIC nie chciał się ustabilizować (przy lekkiej pomocy, coś mu się udało). Zauważyłem, że brakuje mu "pary". Dlatego zamiast bawić się z tą konstrukcją, wydrukowałem jeszcze większe koła, o promieniu samego robota. Dzięki większemu obwodowi, pokonujemy większą drogę w tym samym czasie (kosztem momentu - jak coś pokręciłem, dajcie znać w komentarzach). No i bardzo ważna rzecz, robot przestał upadać - po upadku zaczyna się toczyć. Wyłączyłem wszystkie człony, za wyjątkiem proporcjonalnego. Po kilkunastu minutach eksperymentów, robot osiągnął pozycję stabilną. Mogłem mu w końcu zrobić zdjęcia, kiedy jest włączony: Po eksperymentowaniu z pozostałymi członami, wywnioskowałem, że: człon całkujący (D) próbuje "przewidzieć" ruch robota. Za dużo tego członu spowodowało, że robot cały się trząsł - po odpowiednim dobraniu, robot był w miarę stabilny. człon różniczkujący (I) zamiast w przyszłość, patrzy w przeszłość. Po odpowiednim dobraniu, zmalała ilość oscylacji potrzebnych do osiągnięcia stanu stabilnego. Człon proporcjonalny akurat zrozumiałem "na sucho" - im większy błąd, tym większa moc podawana na silnik. Napotkałem jednak jeden problem, który mnie przerósł... napędy nie są jednakowe. Prawy napęd reaguje na dość małe napięcie i jest dokładny, ale lewy załącza się dopiero od pewnego progu, a wtedy pędzi dość szybko. Na to niestety nie wiem jak zaradzić, może w przyszłości coś będę jeszcze robił. Ważne, że robot spełnił swoje zadanie, bo całkiem dużo się dzięki niemu nauczyłem.

To i ja zgłoszę swoje projekty ^^

Po tym, jak skończyły się pomysły na projekty gdzie było zapotrzebowanie, pojawiły się pomysły na projekty nikomu nie potrzebne. Tak w skrócie, popełniłem to coś - a jest to moduł bazujący na myszce. Tak, zwykłej, komputerowej myszce optycznej - i okazuje się, że z tą myszką można wiele zrobić... Tak jak powiedziałem - w moje ręce wpadła myszka, firmy logitech. Po rozkręceniu, myszka pokazała co było w środku: 3 przyciski, diodę IR i podwójny fototranzystor, kolejny LED z tyłu oraz dwa czipy: własny sterownik Logitecha oraz sensor optyczny ADNS2610. Wylutowałem co mi się przydało, ale uznałem że może warto by poszukać czegoś o samym sensorze w internecie. Okazało się, że ludzie podłączali się pod myszkę do Arduino, a nawet zrobili z niej kamerę! Akurat mój sensor, ADNS2610 jest bardzo dobrze udokumentowany. Po przeszukaniu całego internetu, okazało się, że i ja z tego mogę zrobić kamerę. Pokażę wam zatem efekt moich prac: moduł myszki, z wydrukowaną podstawką, oraz specjalną bibliotekę do Arduino, własnego autorstwa. Tak więc, najpierw podłączyłem myszkę do NodeMCU (ostatnie nano spaliłem...), oraz przeszukałem gotowe kody innych autorów. Większość z nich nie działała, gotowe biblioteki też, jedynie kod tego autora po lekkich modyfikacjach działał. Udało mi się podłączyć gryzonia pod Arduino, oraz sparować z Processingiem. Tak wyglądały pierwsze obrazy: Obrazki udało mi się posklejać w gifa, co pewnie już zauważyłeś/aś. Jest to napis na banknocie "Del. A. Heidrich", o wysokości ok. 1mm. Mogłem na tym skończyć - ot, faktycznie myszki to małe kamery i tyle. Przeczytałem jednak notę katalogową - skąd udało mi się wynieść kilka ciekawych informacji. Przede wszystkim, myszka faktycznie ma fizyczną rozdzielczość 18x18px. Jest zasilana z 5v (3.3v nie działa), do działania wymaga jedynie oscylatora kwarcowego 24MHz oraz kondensatora 2.2uF. Co ciekawe, ma nawet zabezpieczenie antyelektrostatyczne, do 2kV. Najważniejsze jednak była informacja, że ta kamera ma 1500 FPSów! Dlaczego zatem obraz ma 5FPS? Po dalszym odczytaniu dokumentu, okazało się że można odczytywać tylko piksel na jedną klatkę. Daje nam to 324 klatki do uzyskania pełnej ramki, co daje nam ok. 5 FPS. Okazało się także, że z tym sensorem można zrobić o wiele więcej. Bardzo mnie ten wykres zaciekawił - przedstawia on stosunek długości światła (koloru) do reagowania czujnika. Czerwony jak widać jest najlepszym kolorem do wykrywania obrazu, ale myszka jest także czujna na inne kolory. Dlatego wywaliłem starego LEDa, i dołożyłem nową diódkę LED RGB. Modyfikowanie programu było proste: zbieramy 3 osobne ramki, każdą w osobnym oświetleniu, i je łączymy w całość. Efekt był zdumiewająco dobry: Na samej górze dwie animacje - obrazu czarno-białego, oraz kolorowego. Potem "skan" dość małego tekstu "Rzeczpospolita Polska", na tym samym banknocie. Następnie kilka zdjęć kart z monopoly, oraz mój palec przyłożony do sensora. Mimo wszystko, framerate spadł aż do 1FPS - przez co obraz to bardziej pokaz slajdów, gdzie na dodatek widać rozjechane klatki przy szybkich ruchach. Może w przyszłości zrobię mikrofon z zapalniczki, i dostaniemy najtańszą kamerę świata? Następnie zagłębiłem się jeszcze bardziej w notę katalogową. Dodałem własne funkcje odczytujące dodatkowe rejestry, jak ruch relatywny w osi X/Y, poszczególne wartości pikseli. Ubrałem to wszystko w bibliotekę, którą możecie pobrać z githuba. Udało mi się nawet napisać kilka funkcji opartych na bibliotece - dzięki czemu z myszki możemy zrobić czujnik koloru: Ten program pobierał wartość średnią z ramki (myszka ma na to specjalny rejestr), i robił to 3 razy dla każdego koloru. Potem zapalał diodę na odczytany kolor, kiedy kliknąłem klawisz. Odstęp 10ms co zmianę koloru był potrzebny. aby czujnik się "przystosował" do nowego oświetlenia, przez co czujnik ten skanuje z zawrotnymi 50 klatkami na sekundę. Jeszcze szybciej jest z odczytywaniem rejestrów X i Y (praktycznie od razu), dzięki których możemy wykryć relatywny ruch. Może to znaleźć zastosowanie w robotyce, bo enkodery nie powiedzą mi "ugrzęzłem" a "koło się kręci na pełnych obrotach". Ostatnie zastosowanie jakie spróbowałem, to czujnik oświetlenia, czyli po prostu fotorezystor - myszka zwrócona "do góry nogami", oraz pobieranie średniej, najwyższej i najniższej wartości pikseli. To wszystko dalej z myszki za 5zł. Potem pomyślałem, że skoro myszka to kamera, to na 100% mogę nagrać coś większych rozmiarów. Wydrukowałem specjalną podstawkę, do której mogę przykręcić obiektyw z kamery OV7670: Tutaj już nie odważyłem się na kolorowy obraz. Musiałbym chyba cały pokój oświetlać raz na czerwono, potem na zielono, i na niebiesko... tak czy siak, tutaj są prawdziwe fotki z myszki: Od lewej: koło do robota, Eevee z drukarki, moja ręka, moja ręka v2, 123 (odległość 30, 20, 10cm), obraz z monitora. Okazało się także, że wykrywanie ruchu dalej poprawnie działa, więc zrobiłem bardzo prostą obsługę gestów: A tutaj pierwsze na świecie (?) selfie z myszki. Czułem się wtedy jakoś niewyraźnie, mam nadzieję że nie widać. Z takim zestawem można już nagrywać UFO, albo zamontować to jako monitoring sklepu... ale jak widać, z jednej myszki można zrobić bardzo, bardzo wiele. Całość udostępniam w poniższym zipie, gdyby ktoś też chciał sobie zrobić selfie z myszki. Tak jak mówiłem, moduł sobie na razie zachowam do przyszłej konstrukcji. Najlepiej to będzie wykorzystać - jak wspomniałem wcześniej - jako czujnik ruchu, czujnik kolorów czy czujnik gestów. Ta ostatnia opcja chyba będzie najlepsza, bo gotowe moduły już nie kosztują 5zł. Ale nie dewastujcie swoich myszek jak nie mają takiego samego czipu, warto poszukać czy nie jest on kompatybilny z moim lub innym dobrze udokumentowanym - w bibliotece dałem możliwość zmiany rejestrów. I nie, nie nudzi mi się w koronaferie. mouze.zip

No to źle mi powiedzieli :< ważne że działa