Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 2 punkty
    Witam chciałbym dzisiaj przedstawić poradnik wykonania EHRu do ciagnika czyli systemu sterowania tylnim zaczepem. Ja swój zamontowałem w ciagniku Ursus C-360. Tak jak zawsze mam również poradnik w formie video do którego zapraszam: Potrzebne elementy: Arduino UNO Sterownik silnika BTS7960 Potencjometr Przełącznik kołyskowy trójpozycyjny 2x Przełącznik dźwigniowy trójpozycyjny Włącznik kołyskowy trójpozycyjny Włącznik ON - OFF Siłownik liniowy z potencjometrem 25cm 80N Oczka, konektorki, koszulki termo-kurczliwe 2x dioda led Poniżej przedstawiam wam schemat podłączenia wszystkiego Prąd z akulator można rozłączyć wyłącznikiem. Przewody od wyłącznika idą do terownika silnika BTS7960 i do ładowarrki samochodowej która jest rozebrana i są prosto do niej przylutowane kable. Oczywiście można zastosować jakiś rezystor, lecz nie zawsze prąd na akumulatorze wynosi 12V, a więcej, natromiast ładowarka za zakres wejścia od 12 do 24V, a na wyjściu poda nam zawsze 5V. W moim projekcie uwzględniłem tylko regulacje wysokości potencjometrem oraz podnoszenie lub opuszczanie przełącznikami - 1 znajduje się w środku kabiny, oraz po jednym na każdym błotniku. Można oczywiście rozwinąć to o potencjometr do regulacji prędkości i potencjometr do ustlenia maksymalnej wysokości podniesienia przy sterowaniu potenciometrem, jednak mój tata dla którego wykonałem ten projekt, powiedział że nie jest to mu akurat aż tak potrzebne. Dodane są też diody sygnalizujące ruch - zielona przy odpuszczaniu maszyny, czerwona przy podnoszeniu. Na schemacie zapomniałem akura uwzględnić ale należy przed diodami dodać rezystor. Co do siłownika liniowego nie jest to zwykły model, ponieważ ma on wbudowany potencjometr do odczyty wysunięcia, dzięki czemu można nim dokładnie sterować za pomocą potencjometru z kabiny. W polsce taki siłownik albo jest ciężko odtępny albo baardzo drogi dlatego ja swój zakupiłem na Aliexpress, i wyniósł mnie on jakieś 250zł. Czerwony i czarny kabel który z niego odchodzi podłączamy do naszego sterownika BTS7960. Co do podłączenia potencjometru to nawet na stronie sklepu było to źle opisane, lecz po kilku próbach udało mi się znaleźć właściwe przewodu, tak więc - Biały kabel (który u mnie na shcemacie jest pokazany jako czerwony z pustym środkiem) podłączamy do 5V, żółty kabel to masa czyli wpinamy go do pinu GND, zaś niebieski kabel podłączamy do pinu analogowego na płytce Arduino, ja podłączyłem pod A0 i tak jest to uwzględnione w kodzie programu. Całość jest schowana i zabezpieczona przed kurzem w tunelu od Mazdy MX-5. Kable są wypuszczone przez dławnice, spód jest zrobiony z płyty OSB, a wszystkie szpary i dziurki są zalepione silikonem. Wszystkie kabelki które są podłączone od arduino, sterownika i innych rzeczy są zalane klejem na gorąco aby nie wypieły się od wibracji w ciągniku. Tunel jest przykręcony do błotnika, tak samo siłownik, a z drugiej strony jest on przykręcony do dźwigni od ponoszenia tylniego zaczepu. Przejdźmy teraz do kodu programu który jest wgrany do arduino. Na początku otwieramy program Arduino IDE i przechodzimy do zakładki Narzędzia > Zarządzaj bibliotekami... i wpisujemy elaspedMillis i instalujey bibliotekę o tej nazwię ( u mnie znajduje się ona na drugiej pozycji po wyszukaniu). Następnie kopiujemy kod z tej strony: Pastebin z kodem i wklejamy go do Arduino IDE oraz wgrywamy. Po wgraniu siłownik automatycznie wysunie się do maksymalnej pozycji i wróci do minimalnej (i dzieje się to za każdym razem po podłączeniu arduino do prądu. Było by to uciążliwe w ciągniku więc to zmienimy). Otwieramy monitor portu szeregowego i przekręcamy nasz potencjometr od końca aż siłownik cały się wysunie i odczytujemy wartość która jest przy Actuator reading, przekręcamy następnie potencjometr w drugą stronę, aż siłownik cały się wsunie i ponownie oczytujemy wartość Acurator reading. Możemy teraz zamknąć monitor portu szeregowego i w linijce maxAnalogReading, moveToLimit(1) zmieniamy na naszą wartość którą odczytaliśmy jako pierwszą ( w moim przypadku było to 937). W linijce pod spodem czyli minAnalogReading zmieniamy moveToLimit(-1) na wartośc którą odczytaliśmy przy maksymalnym wsunięciu siłownika ( u mnie było to 242). Dodatkowo możemy usunąć linijki które nie są nam już potrzebne czyli linijki od 79 do 90 włącznie, i od 66 do 70 włącznie. W taki oto sposób wykonaliśmy EHR do ciągnika który ułatwia pracę w polu. Tutaj filmik z pokazaniem że EHR działa (UWAGA! sterowanie potencjometrem na filmiku wydaje się że działą słabo, lecz dzieje się to dlatego że kultywator opiera się później na ziemi i nie opuszcza się dalej oraz czas reakcji podnośnika wydaje się długi z powodu nie rozgrzanego oleju w pompie podnośnika) Mam nadzięję że poradnik przyda się kiedyś komuś. Dzięki za przeczytanie i pozdrawiam.
  2. 1 punkt
    No wreszcie - po jakimś szale na prezenty, naprawy różnych domowych urządzeń i inne przyziemne sprawy mogłem zabrać się za następnego z rodziny Konserwatorów Płaskich Powierzchni - czyli małego Kopłapowa. Miał on w założeniu służyć do wycierania podłogo w trudniej dostępnych miejscach (np. pod kabiną prysznicową) więc siłą rzeczy musiał byc jak najmniejszy. Założenia były proste: zasilanie 1 x 18650; dwa silniczki N20 do napędu z driverem DRV8825; z przodu pojedyncza gąbka kuchenna; wysokość taka, aby się zmieścił pod brodzikiem; z czujników: zderzak, żyroskop i kilka czujników odbiciowych; Arduino Pro Mini jako "mózg" urządzenia; żadnego skomplikowanego algorytmu - ma się przejechać po podłodze i tyle, z możliwością zdalnego sterowania. Z takimi założeniami zabrałem się do roboty. Sterownik już miałem - kiedyś zrobiłem sobie coś w rodzaju uniwersalnego nadajnika, sprawdził się już w trzech konstrukcjach a więc tę część miałem gotową. Tym razem postanowiłem w maksymalnym stopniu wykorzystać drukarkę. Ponieważ miałem felgi z kół Pololu (opony zostały użyte w innym projekcie) wystarczyło dodrukować jakieś ładne oponki z TPU. Również dolna płyta podwozia wraz z koszykiem na 18650 oraz mocowaniami na ładowarkę, przetwornicę i inne drobiazgi typu wyłącznik została wydrukowana w jednym kawałku. Zadowolony z siebie zmontowałem podwozie, podłączyłem prowizorycznie silniczki pod 5V... i w tym momencie szczęście się skończyło. Okazało się, że robot nawet po lekkim dociążeniu jest jeszcze za lekki i nie da rady przepchnąć gąbki nawet po śliskich kafelkach. Zmartwiony odstawiłem konstrukcję na skraj biurka i zająłem się swoimi sprawami. Na szczęście był to skraj biurka przy którym pracuję i co chwila chcąc nie chcąc spoglądałem na biednego robocika. Jak go wykorzystać... Pomysł przyszedł sam, gdy nastąpiłem bosą nogą na jakąś śrubkę. A gdyby tak wyposażyć go w magnes i kazać zbierać śrubki z podłogi? Wywaliłem uchwyt gąbki, w to miejsce zamontowałem obrotowe kółko (o nim więcej w dalszej części), uchwyt na magnesy i również podłączając bezpośrednio do przetwornicy silniczki puściłem go po podłodze. Okazało się, że śrubki i podobne niewielkie metalowe farfocle zbiera doskonale! Tak więc robocik zmienił swoje przeznaczenie, miałem już gotowe podwozie i mogłem zabrać się za dalsze projektowanie. Oczywiście - potrzebne były nowe założenia. Przede wszystkim - wysokość nie była już krytyczna (robot miał zbierać śrubki porozrzucane po podłodze i nie wjeżdżać do łazienki). Z uwagi na to zrezygnowałem z czujników odbiciowych, w ich miejsce postanowiłem zamontować obrotowy laserowy czujnik TOF o kącie 180°. Pozostał oczywiście żyroskop. Z uwagi na przykre doświadczenia z MPU6050 przy okazji zakupów w Botlandzie zamówiłem moduł L3G, czujnik VL53L0X kupiłem już wcześniej, tak więc zabrałem się za dalsze projektowanie. I tu mała dygresja: odrzuciłem MPU6050 z uwagi na to, że potrafił zawiesić Arduino po kilkudziesięciu sekundach od włączenia (a z tego co wyczytałem w sieci nie tylko ja miałem z tym problemy). Oczywiście: nie doczytałem, że dotyczy to wyłącznie odczytu danych z DMP, odczyt surowych danych z żyroskopu i akcelerometru był prawidłowy. Dopiero po zmontowniu całości przypadkiem natknąłem się na nową wersję biblioteki która (podobno) nie sprawia takich problemów... a szkoda, bo niepotrzebnie wydałem trzy dychy na nowy żyroskop Ale wróćmy do robocika. Ponieważ laser na serwie i tak musiał dość mocno wystawać nie było konieczności zachowania wysokości reszty konstrukcji. Postanowiłem zrobić więc coś podobnego jak w poprzednim robocie - podłoga ze spienionego PVC (idealna do eksperymentów z uwagi na łatwość obróbki), do niej mocowane serwo i płytka z elektroniką. Z tamtej konstrukcji skopiowałem również zawieszenie zderzaka i przekładnię do serwa obracającego laser. Płytka z elektroniką miała początkowo być wykonana na frezarce - niestety, wskutek pandemii zostałem odcięty od warsztatu kolegi i musiałem zadowolić się płytką uniwersalną. Przyszedł więc czas na najprzyjemniejszą część pracy programowanie. Na zdjęciu wyżej widać przytwierdzony do robota najnowszy model SMARDZ-a. Tym razem SMARDZ ma własne zasilanie (akumulatorek Li-Ion 1000 mAh, ładowarka i przetwornica) co uniezależnia go od akumulatorów robota i - co ważniejsze - przy większych wstrząsach (np. uderzenie w przeszkodę) nie ma możliwości, że zrobi sobie reset. Większych niespodzianek nie miałem z wyjątkiem jednej - ale za to bardzo śmiesznej... Otóż po zmontowaniu wszystkiego na płytce uniwersalnej jak zwykle przedzwoniłem wszystkie połączenia. Po stwierdzeniu że wszystko jest w porządku rozpocząłem testowanie. Wszystko działało - oprócz serwa. Zdjąłem płytkę, wyjąłem Arduino, sprawdziłem połączenia - wszystko było w porządku. Ki diabeł? Zacząłem szukać w programie czy coś mi nie blokuje timera - nie, najprostszy program ruszający serwem z przykładów też nie chciał działać. Co prawda serwo było sprawdzone (przed zamontowaniem musiałem ustawić środkowe położenie, a do tego używałem testera serw) - ale wiadomo, popsuć się mogło. Niestety - inny egzemplarz zachował się tak samo. Co ciekawsze - mały HD-1370A zaczął kręcić się w kółko... Nie bardzo mi się chciało podpinać sondę, ale jakoś chęć zbadania przyczyny owego dziwacznego działania przeważyła nad lenistwem. No i co się okazało? Otóż na nóżce 8 do której podłączone było serwo radośnie trwało 5V. Wtedy sobie przypomniałem, że płytkę Arduino wziąłem z pudełka gdzie leżą wszystkie podejrzane moduły (jako że miał wszystkie piny polutowane) - po prostu wyjście 8 było najprawdopodobniej uszkodzone i zwarte na stałe z Vcc Na szczęście połączenia robione Kynarem mają to do siebie że szybko można je zmodyfikować - podłączenie serwa do wolnego pinu obok pomogło! Ech, znowu się okazało, że elementy sprawne działają z reguły lepiej od uszkodzonych! I jeszcze drobiazg - w pewnym momencie jeden z silniczków uległ uszkodzeniu (mechanicznemu). Chciałem kupić dwa w Botlandzie na wypadek gdyby drugi też miał jakieś skłonności samobójcze - niestety, już nie było (tzn. był jeden ale trochę się bałem). Kupiłem więc podobne - działają chyba nawet lepiej. W sumie mam na płytce: Arduino Pro Mini cztery mikroswitche zderzaków (połączone parami, czyli wykrywane jako dwa oddzielne) podpięte do jednego pinu analogowego moduł radiowy nRF24L01 (zasilany z wyjścia VDD żyroskopu) żyroskop L3GD20H driver DRV8835 buzzer służący do wygrywania różnych krzepiących melodyjek związanych z wykonywaną funkcją wyjścia na silniki, serwo i diody WS2812 (wskaźnik wykonywanej funkcji oraz wskaźnik poziomu naładowania akumulatora). Wszystko zasilane z jednego napięcia 5V z przetwornicy MT3608, do pinu analogowego podpięte wejście przetwornicy (kontrola napięcia akumulatora). O dziwo działa bez żadnych dodatkowych kondensatorów z wyjątkiem jednego 100nF przy module radiowym i dwóch przy silnikach. W efekcie robot wygląda tak: Tak więc robot w tej chwili potrafi realizować następujące programy: Sterowanie zdalne (ot, wielki mi program). Jedyne co go różni od samochodzika wnuczka na bateryjkę to fakt, że używa żyroskopu do jazdy prosto (podobnie jak reszta programów). Wałęsak - Bradiaga - najprostszy z możliwych - przejeżdża kawałek i skręca sobie w losowym kierunku. Po spotkaniu z przeszkodą po prostu cofa i zakręca. Wałęsak - Moocher - taki włóczęga bardziej inteligentny. Używa lasera do stwierdzenia czy nie dojeżdża do przeszkody oraz do wyszukania najlepszej (w jego rozumieniu najdłuższej) trasy do dalszej jazdy po spotkaniu z przeszkodą lub gdy mu się zamami zmiana kierunku. Odplamiacz - jedzie sobie po spirali. W przypadku napotkania na przeszkodę wykonuje wcześniej zaplanowany skręt, poprzedzając lekkim cofnięciem jeśli sygnał pochodzi od zderzaków a nie lasera.. Przerywa pracę, gdy nie może skręcić (tzn. w czasie skrętu dostanie sygnał od zderzaków). Polowiec - obrabia prostokątny kawałek podłogi - przejeżdża kawałek, zawraca, znowu przejeżdża, zawraca... jakby orał pole. Również używa oprócz zderzaków lasera jako czujnika przeszkody. Ponieważ zawraca zawsze na zasadzie zastopowania jednego koła (wewnętrznego) przesuwa się nieco za każdym nawrotem. Podobnie jak Odplamiacz przerywa pracę, gdy nie może zawrócić. Patrol - robot stara się ustawić jak najbliżej ściany równolegle do niej, a następnie jeździ od ściany do ściany aż do momentu, kiedy nie może zawrócić. Kod jest w sumie bardzo prosty, jednak chciałbym zwrócić uwagę na dwie rzeczy: Używam funkcji printf do wyświetlania różnych informacji o tym, co robi robot. Ponieważ wszystkie funkcję dotyczące żyroskopu działają na liczbach float, musiałem zmusić Arduino do wyświetlania ich właśnie przez printf. Niestety - nie ma możliwości ustawienia tego dla pojedynczego szkicu, ale globalne ustawienie jest bardzo proste: otóż w katalogu, gdzie znajduje się plik platform.txt dla naszego Arduino (czyli w tym przypadku ARDUINO_HOME/hardware/arduino/avr) trzeba założyć nowy plik o nazwie platform.local.txt, a w nim umieścić skopiowaną z platform.txt linię rozpoczynającą się od ciągu "recipe.c.combine.pattern=" z jedną drobną modyfikacją: na końcu linii należy (po spacji) dodać: -Wl,-u,vfprintf -lprintf_flt W przypadku wersji 1.8.12 (a podejrzewam, że wielu innych) będzie to wyglądać tak: recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o {build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -l m -Wl,-u,vfprintf -lprintf_flt Druga sprawa to laser. Na potrzeby programu zmodyfikowałem nieco bibliotekę Pololu dodając możliwość nieblokującego odczytu danych. Mimo to czujnik zachowywał się dość dziwnie: czasami zwracał bardzo pięknie prawidłowe odległości, a czasami kompletnie wariował. Bliższe przyjrzenie się problemowi poskutkowało stwierdzeniem, że czujnik zwraca nieprawidłowe dane po wgraniu kolejnej wersji programu (ściślej po programowym resecie Arduino). Ponieważ w bibliotece zabrakło funkcji resetowania lasera postanowiłem wypróbować najprostszą możliwość - w funkcji setup przed init() wstawiłem następujący kod: lidar.writeReg(VL53L0X::SOFT_RESET_GO2_SOFT_RESET_N, 0); delay(100); lidar.writeReg(VL53L0X::SOFT_RESET_GO2_SOFT_RESET_N, 1); delay(100); Od tej pory laser przestał mieć fochy i grzecznie zwraca odczytane odległości. I jeszcze jedna uwaga dla kogoś, kto na tej podstawie chciałby zbudować własną wersję robota. Otóż funkcja "Patrol" w teorii działa, w praktyce jednak robot nie jest w stanie ustawić się dokładnie równolegle do ściany. Co najmniej w czasie pierwszego przejazdu powinno się dokonać korekty... niestety, o ile laserowy czujnik jest wystarczająco precyzyjny, o tyle brak enkoderów nie pozwala na pomiar przebytej odległości. Prawdopodobnie i tak dałoby się to zrobić oceniając mniej więcej prędkość robota, i dokonując korekty zanim robot dojedzie do ściany z przodu... ale prawdę mówiąc już mi się nie chciało Natomiast uważam zadanie za całkiem ciekawe i pozostawiam sobie na przyszłość - na razie muszę niestety przerwać pracę nad robocikiem i zająć się bardziej przyziemnymi sprawami Aha, obiecałem jeszcze o kółku. No więc początkowo chciałem wyposażyć robota w kulkę podporową. Bliższa analiza zawartości szuflady wykazała, że mam dwa rozmiary: mianowicie za dużą i za małą. Drukowanie kulki raczej nie wchodziło w grę, natomiast obrotowe kółko można wydrukować na dowolej taniej drukarce. Wygląda to tak: Oprócz trzech drukowanych elementów do zrobienia kółka potrzebne są: 1 x śrubka M3x8 1 x śrubka M3x16 2 x nakrętka M3 2 x łożysko kulkowe 3x10x4 Kółko mocowane jest dwiema śrubkami M2x10 do podwozia. Załączam plik OpenSCAD (gdyby ktoś chciał sobie takie kółko zmodyfikować do własnych potrzeb) oraz pliki STL (gdyby ktoś chciał tylko wydrukować bez modyfikacji). Kółko dopasowane jest wysokością do silników Pololu Micro (lub tańszych N20) mocowanych bezpośrednio pod dolną płytą podwozia oraz kół o średnicy 42mm. Łożyska trzeba wcisnąć we właściwe otwory (ja użyłem zwykłego małego imadełka), gdyby okazały się za luźne należy po prostu w OpenSCADzie zmniejszyć nieco ich średnicę. Nie załączam schematu ani programu sterownika - nie jest specjalnie udany, używam go przede wszystkim dlatego, że nie chce mi się robić innego. Lepiej zastosować np. bezprzewodowy gamepad (w sumie cenowo wyjdzie na jedno). No i na koniec filmik demonstrujący działanie robota - niestety nie we wszystkich programach (Moocher i Patrol wymagają więcej miejsca, a na dziś nie bardzo dysponuję takim które się nadaje do kamery). A - oczywiście winien jestem jeszcze wyjaśnienie, skąd takie dziwne imię Zbignaś. To po prostu skrót od Zbieracz Gwoździków, Nakrętek i Śrubek Pora na podsumowanie i wnioski. A więc: Robot powinien być okrągły - konstruktorzy Roomby nieprzypadkowo tak go zaprojektowali. Zderzak powinien obejmować cały obrys robota (nie tylko przód jak w Roombie) oraz całą wysokość (robot nie może wjechać pod mebel jeśli jest za mało miejsca). Nic nie może wystawać ponad zderzak Laser musi obejmować 360°, oś obrotu (niekoniecznie sam laser) powinna być w środku robota (jak to połączyć z poprzednim punktem?) Enkodery nie muszą być super dokładne kwadraturowe, wystarczą zwykłe niewielkiej rozdzielczości, ale powinny być. W załączniku: program robota, zmodyfikowana biblioteka do czujnika, pliki do kółka oraz (może się komuś przydadzą) opona i felga (STL i SCAD, do opony/felgi potrzebny openscad w wersji nightly).Zbignas.zip W razie pytań i pretensji jestem do dyspozycji. Gdyby coś z moich STL-i było potrzebne proszę o informację (tylko nie na priv, błagam).
  3. 1 punkt
    @kabaczek bo jak robisz pullup to twój przycisk jest że tak ujmę musi przeciwstawić się temu do czego podciągasz (tu 5V) i musi być jedną nóżka na masie - wtedy gdy będzie wciśnięty to ściągnie stan wysoki do masy. A na zdjęciu drugi kabelek masz wetknięty w wyjście 5V. Przełóż je na masę, daj w kodzie PULL_UP i zewrzyj pin 7 i kabelek z masy. I jeszcze uwaga #definy lepiej daj na gorze kodu, nie w żadnej funkcji, tam gdzie masz #import itp. Ok, dzięki
  4. 1 punkt
    @011010110110110 Fajnie, autor kursu na pewno doceni Wygląda dobrze, fajnie że trzymasz się dobrych zasad tworzenia schematów jak wykorzystanie etykiet, ciągnięcie zasilania + w górę, a masę w dół. Tak trzymaj!
  5. 1 punkt
    @macias2k4 Witam serdecznie na forum To co piszesz wygląda bardzo ambitnie, na pewno dobrze znasz C++ i program może wyglądać ciekawie. Akurat w Arduino i podobnych sporo twórców ma podstawowe pojęcie o języku także myślę, że mogło to by być coś naprawdę wartościowego. Np z STM32 już jest inna sprawa, bo jest to bardziej wymagający temat. Zachęcam zatem żebyś podzielił się swoim projektem na forum, na pewno będzie on motywujący dla innych czytelników, a sam chętnie bym spojrzał @011010110110110 CUDA są w GPU taki żarcik z rana przy kawce.
  6. 1 punkt
    @Oskar_Zaremba w 9 części tego kursu jest odpowiedź jak używać ekspander, znajdziesz to w spisie treści. Czy czujnik ultradźwiękowy można podpiąć do ekspandera? Obawiam się że nie, ale możesz spróbować. Ekspander z faktu sterowania szeregowego jest nieco wolniejszy. Lepiej żebyś podłączył dalmierz do Arduino a ekspanderem sterował jakieś LEDy, przyciski, przekaźniki itp.
  7. 1 punkt
    Nie - funkcja map działa na long int. Możesz zrobić podobną funkcję dla float/double: double fmap(double x, double in_min, double in_max, double out_min, double out_max) { return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min; } W opisanym przypadku można jednak skorzystać z map() zmieniając np. zakres: float napiecie = map(odczytanaWartosc, 0, 1023, 0, 500) / 100.0; lub np. mierzyć napięcie w miliwoltach lub decywoltach: int napiecie = map(odczytanaWartosc, 0, 1023, 0, 5000); Polecam ten drugi sposób.
  8. 1 punkt
    Hej. Właśnie ukończyłem cały kurs i chciałbym bardzo podziękować za jego publikację - teraz EAGLE to nie jest już dla mnie taka czarna magia i umiem narysować to, co potrzebuję. Wiadomo - na razie potrzebuję trochę praktyki, więc będę rysował sobie schematy i tworzył do nich płytki - połączę 2 rzeczy na raz - będę przerabiał kurs elektroniki i jednocześnie będę tworzył schemat oraz płytkę do każdego układu z kursu.
  9. 1 punkt
    Kurka z tym układem Darlingtona to byłem w szoku. Przewody nie były nawet blisko siebie ani tego "ołówkowego rezystora", a dioda się świeciła. Dobrze że w komentarzach opisali ten sam problem hahah
  10. 1 punkt
    Nic nie jest głośne - po prostu nie masz skali odniesienia bo nie ma innych dźwięków. Poza tym tu akurat robot jeździ po panelach pod którymi jest pusto i robi się z tego klasyczny rezonator
  11. 1 punkt
    Dość dobry artykuł, jednak nie bez drobnych pomyłek: W sekcji "Technologie wielowątkowe w Qt" napisane jest: "(...) klasa QThread. Klasa ta umożliwia utworzenie wątku, który istnieje od momentu jego uruchomienia aż do końca działania programu." Nie jest to cała prawda. Wątek utworzony przez klasę QThread przestaje istnieć, kiedy metoda QThread::run() zwróci kontrolę (return). W domyślnej implementacji jest tak, jak napisał Pan w artykule. Niemniej jednak, metoda QThread::run() jest wirtualna, więc można ją nadpisać (override). To drobny detal, jednak napisał Pan o nim pogrubioną czcionką, dlatego zwracam uwagę. W sekcji "Przykład praktyczny" opisując nadpisywanie wirtualnego destruktora QObject używa Pan słowa konstruktor. Taki chochlik "drukarski" ;-) Brakuje mi też przykładu automatycznego rozwiązania problemu użycia obiektów klas niejawnie współdzielonych (implicitly shared) w wielu wątkach poprzez przekazywanie ich mechanizmem sygnałów i slotów - zgodnie z sugestią dokumentacji Qt. Poza tym, bardzo dobra robota! :-)
  12. 1 punkt
    Oj, pisz dokładniej (między wyjście Arduino a Vcc czyli +5V), bo jak znam życie to połowa szanownych kursantów podepnie drugi koniec rezystora pod Vin albo jakimś drucikiem do gniazdka zasilania i będzie się zastanawiać dlaczego później coś nie działa
  13. 1 punkt
    Nie wiem, czy autor tematu wie jak wygląda praca etatowa przy projektach komercyjnych z arduino, zakładam, że nie. Czuję, że sam do końca nie wie, gdzie chciałby pracować, bo szczerze powiedziawszy dwa lata pracy przy frontendzie, to stosunkowo mało. Jest jeszcze backend, desktop, mobile, etc. Uważam, że najlepszym rozwiązaniem będzie poszukanie pracy jako specjalisty IT w firmie produkcyjnej - niekoniecznie dużej. Dzięki takiemu stanowisku, będzie mieć większe pole do działania. Będzie mógł wdrażać swoje pomysły, pisać programy (bo lubi programować), a nawet używać w swoich projektach raspberry, czy arduino. Ja sam pracuję w podobnej firmie, dzięki czemu nie dość, że piszę pełno skryptów ułatwiających codzienną pracę pracownikom, usprawniam pracę z ERP (WMS+MRP), tworzę serwisy internetowe jak firmowy dashboard i wykorzystuję w wielu projektach raspberry. Ostatnio przygotowałem malinkę do testowania penów usb. Bardzo ciekawa praca i jest się w ruchu. Masz pomysł do użycia arduino, który wesprze jakiś proces w firmie? To dostajesz zielone światło i możesz działać.
  14. 1 punkt
    Robot unikający przeszkód z regulacją napędu silników prądu stałego Cześć! Ponad rok temu skonstruowałem w ramach przedmiotu na studiach robota unikającego przeszkody. Po czasie pomyślałem, że konstrukcją warto podzielić się na Forbocie. Zakres projektu Robot porusza się na dwóch kołach i omija przeszkody wykrywane za pomocą czujnika ultradźwiękowego. Dużo pracy włożono w sterowanie silnikami prądu stałego, które stanowią napęd robota. Mimo że zakres zachowań platformy nie jet zbyt szeroki, to wartość projektu leży w algorytmach teorii sterowania, które skonstruowano by zwiększyć precyzję ruchów. W zakres prac projektowych weszły: projekt platformy robota i jej wykonanie w technologii druku 3D (Fusion 360), projekt układu drukowanego z mikroprocesorem Atmega32u4, mostkiem H oraz paroma innymi peryferiami (Autodesk Eagle), oprogramowanie robota pozwalające na wykrywanie i omijanie przeszkód (biblioteki i bootlader Arduino), konstrukcja pętli sprzężenia zwrotnego dla silników oparta na użyciu enkoderów szczelinowych, algorytm regulatora PI do synchronizacji prędkości kół przy jeździe na wprost (poprawia utrzymanie kierunku jazdy), algorytm zagnieżdżonego regulatora obrotu platformy o zadany kąt (algorytm podobny jak ten stosowany w serwomechanizmach), prosta identyfikacja parametrów transmitancji użytych silników i trochę rozważań na temat możliwości strojenia regulatorów przy pomocy metody linii pierwiastkowych. W ramach zaliczenia projektu powstał dosyć długi raport, gdzie jest opisane jak zrealizowano poszczególne części projektu, dlatego nie ma chyba potrzeby przedstawiać w poście szczegółów po raz drugi. Gdyby ktoś szukał informacji o przenoszeniu swojego projektu z Arduino na własną płytkę PCB (z działającym USB na Atmedze32u4), konstrukcji systemów regulacji w praktyce, czy budowy własnych serwomechanizmów to można tam znaleźć działające przykłady. Kod projektu i dokumentację można znaleźć na GitHubie. Oczywiście projekt nie jest idealny, szczególnie że powstał już jakiś czas temu, a wraz ze zdobywaniem doświadczenia dostrzega się coraz więcej błędów. Na koniec dorzucam parę grafik i gifów, więcej można znaleźć w podlinkowanym raporcie i repozytorium. Ujęcia na robota z różnych stron Wierzchnia strona płytki PCB, spód oraz schemat elektryczny w raporcie Utrzymywanie kierunku jazdy Obrót o zadany kąt
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...