Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 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).
  2. 3 punkty
  3. 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ę.
  4. 2 punkty
    @Krystyna Improwizowanie dobra rzecz, ale nie musisz improwizować. Jeśli kupisz koła które linkowałem i te mocowania to razem wszystko będzie pasowało do silników nema 17. Oczywiście o ile tak jak gdzieś sprawdziłem ich oś ma średnicę 5mm.
  5. 2 punkty
  6. 2 punkty
    @Karliko takie przewody spokojnie poradzą sobie z prądem od tych małych silników, nie musisz się tym przejmować
  7. 2 punkty
    Po półtora miesiąca przerwy czas coś napisać. Większość tego czasu spędziłem na ogarnięciu, czemu ROS2 nie działa i to była faktycznie jego, a nie moja wina . Na początku po jakiejś aktualizacji okazało się, że przestała działać główna jego funkcjonalność, czyli protokół porozumiewania się między węzłami (osobnymi programami). Nawet przykładowe programy nie działały, publisher wysyłał wiadomości w eter a do subscribera już nic nie docierało. Nareszcie po kilku dniach przyszła kolejna aktualizacja, która naprawiała ten problem i mogłem pisać dalej, tylko pojawił się kolejny problem. ROS2 nie widział paczek napisanych w Pythonie. W ROS2 struktura prjektu wygląda tak, że jest folder z folderem `src`, w którym w osobnych folderach znajdują się poszczególne paczki. Każda paczka zdefiniowana jest przez plik `package.xml` i do tego paczka C++ wymaga `CMakeList.txt`, a paczka Pythona `setup.py`, więc przy budowaniu projektu faktycznie są inaczej traktowane. Problem był o tyle trudny do zdebugowania, że paczki przy budowaniu się pokazywały, ale ROS2 ich nie widział przy próbie uruchomienia programów z tych paczek, mówił, że nie istnieją. Okazało się, że w pliku `setup.py` należy dołożyć dodatkowy krok budowania, który polega na skopiowaniu pustego pliku o nazwie takiej, jak paczka do folderu, który ROS2 wykorzystuje do indeksowania paczek. Nie wiem, czemu wcześniej działało wszystko bez tego i nagle przestało, ale chwilę na to poświęciłem. Jeśli ktoś byłby zainteresowany, to takie linijki są potrzebne w `setup.py`: data_files=[ ('share/ament_index/resource_index/packages', ['resource/' + package_name]), ('share/' + package_name, ['package.xml']), ], Oprócz tego miałem problem ze stworzeniem własnego typu serwisu, który korzystał z typów wbudowanych w ROS2 (z paczki geometry_msgs), najwyraźniej dlatego, że było coś nie tak w implemetacji tych typów. Tutaj już mi się nie chciało dochodzić do przyczyny w kodzie źródłowym ROSa i po prostu zdefiniowałem własny typ, który miał dokładnie takie same informacje (tj. informacje o pozycji). Po pokonaniu przeciwności ze strony ROSa mogłem nareszcie wziąć się do właściwego kodzenia. Zaimplemetowałem to, co deklarowałem w poprzednim poście, czyli ustawianie nóg i ciała względem "świata", zamiast względem siebie. Do przejścia między układami bazy nogi i bazy świata używałem serwisu ROSa, który sam się tym zajmuje, a do przejścia z bazy świata do końcówki nogi mnożyłem macierze, bo nie publikowałem ich pozycji, tylko trzymałem je w pamięci programu. Robot teraz potrafi poruszać ciałem względem świata z nogami stojącymi nieruchomo, ogarnia zarówno translację, jak i rotację ciała (choć na filmiku poniżej jest tylko translacja, bo rotację zaimplemetowałem jakieś dwie godziny później). Z rzeczy, których nie ma na filmiku, to zmieniłem nieco ułożenie kolana. Na filmiku robot nie może go zginać mniej niż 90*, bo inaczej dochodzi do kolizji z udem. Wystarczyło przestawić na drugą stronę mocowania, podobnie jak to widać na mocowaniu "biodrowym". Dzięki temu już mu lepiej wychodzi kucanie. Co chcę zrobić w najbliższym czasie: 1) Umieścić dane o charakterystyce nóg w jednym globalnym pliku, teraz jest to zahardkodowane w kodzie i nie sprzyja zmianom. 2) Poprawić odwrotną kinematykę dla nowych danych i uwzględniać przesunięcie osi w biodrze, bo wcześniej tego nie brałem pod uwagę i niby działało, ale przyda się dokładna pozycja końcówki nogi. 3) Prosty chód w stylu: idź do przodu. @deshipu czy dobrze rozumiem: przez analogię do regulatorów, pojazd wirtualny to jest pozycja zadana robota, którą rzeczywisty układ powinien osiągnąć? Jeśli tak, to przy zachowywaniu równowagi statycznej (nie ma potrzeby balansowania, robot się nie potyka) te układy powinny się cały czas pokrywać i różnice powinny się pojawić się tylko w przypadku zewnętrznych sił, np. kopiących panów z Boston Dynamics?
  8. 2 punkty
    Zaraz zaraz... Kod pierwszy: extern void digitalWrite(int, int); #define PIN 2 int main(void) { digitalWrite(PIN,1); } Kod drugi: extern void digitalWrite(int, int); const int PIN = 2; int main(void) { digitalWrite(PIN,1); } I teraz: $ avr-gcc -Os -S -o k1.s k1.c $ avr-gcc -Os -S -o k2.s k2.c $ diff k1.s k2.s 1c1 < .file "k1.c" --- > .file "k2.c" 23a24,29 > .global PIN > .section .rodata > .type PIN, @object > .size PIN, 2 > PIN: > .word 2 24a31 > .global __do_copy_data Gdzie to takie same? Co robię źle?
  9. 2 punkty
    No i też to, że rejestry 74HC są słabsze niż tranzystory więc driver powinien wyglądać tak, że to elektrody wspólne (cyfry) powinny być sterowane przez tranzystory a rejestr bezpośrednio powinien napędzać tylko pojedyncze segmenty. W Twoim przypadku musiałbyś zmienić tranzystory na pnp i podłączyć je od strony anod wyświetlaczy (od plusa) a segmenty przez oporniki do wyjść rejestru. Wtedy w tym pierwszym rejestrze wybierałbyś konkretną cyfrę stanem niskim i podobnie, segmenty w niej także zapalałbyś stanem niskim w drugim rejestrze. Weź pod uwagę, że prąd chwilowy segmentu w takim multipleksowaniu musi być ok. 4x większy niz statyczny, bo segment świeci tylko przez 1/4 czasu. Dlatego policzone(?) dla stanu ustalonego oporniki 220Ω mogą być sporo za duże już nawet dla niezłych (jasnych) wyświetlaczy. Co więcej, obecnie zmuszasz słabiutkie wyjście układu 74HC.. do zapalenia całej cyfry złożonej być może z 8 segmentów, a to może oznaczać zapotrzebowanie na prąd wypływający z wyjścia rzędu 100mA przy możliwościach tego scalaka na poziomie 5-10mA.. Tak więc do roboty: kupujesz 8 x pnp + mniejsze oporniki i przerabiasz układ na odwrotny bo ten po prostu nie pasuje do wyświetlaczy ze wspólną anodą i raportujesz wyniki. Pamiętaj też o ośmiu opornikach w bazach tranzystorów, bo to co obecnie zrobiłeś to jakaś herezja. Ile prądu wpływa do baz Twoich npn? Ograniczasz go czymś czy płynie "ile fabryka dała"? A na koniec, gdy już zrozumiesz jak to działa (w sumie to proste) to pomyśl o gotowym rozwiązaniu typu MAX7219, bo ten scalak robi to samo co skleciłeś na kolanie, ale dla 8 wyświetlaczy i na dodatek umie sterować jasnością. Niestety - o ile pamiętam - działa tylko z wyświetlaczami ze wspólną katodą: https://botland.com.pl/pl/wyswietlacze-segmentowe-i-matryce-led/2996-modul-8-x-wyswietlacz-8-segmentowy-spi.html lub 4 cyfry na TM1637: https://botland.com.pl/pl/wyswietlacze-segmentowe-i-matryce-led/5973-modul-4x-wyswietlacz-7-segmentowy-interfejs-cyfrowy.html Oba mają interfejs cyfrowy więc procesor nie musi zajmować się samym multipleksowaniem. Wysyłasz dane (numer i wygląd znaku) szeregowo do chipu i zapominasz o sprawie.
  10. 2 punkty
    Wyrazistość obrazu nie zależy od siły podświetlania. Poeksperymentuj z kontrastem. Poszukaj linijki: lcd_cmd(0x80 | 0x2f); //Ustawienie kontrastu i zmień 0x2f na inna wartość, np: lcd_cmd(0x80 | 0x3f); //Ustawienia kontrastu Pozdrawiam, Marek
  11. 1 punkt
    Dziękuję za opinię Z mojego punktu widzenia nerwową atmosferę mogą wywołać tylko odpowiadający. Przecież żadna "afera" nie bierze się z tego, że ktoś zadał niechlujnie pytanie. W mojej "utopijnej krainie" w takiej sytuacji zwyczajnie osoba taka nie otrzyma odpowiedzi lub (najwyżej) zostanie poproszona o szczegóły i do takiego podejścia zachęcam. Nie słyszałem, aby jakieś forum miało złą opinię z powodu źle zadawanych pytań. Natomiast wiele for ma zła opinię przez sposób reakcji na źle zadane pytania. PPF pierwotnie składało się z 12 punktów dla pytających i 12 punktów dla odpowiadających. Zrezygnowałem jednak z tego, bo w takiej formie nikt by tego nie czytał. Ostateczny dokument jest skróconą wersję, którą może ktoś przeczyta. Uznałem, że StackExchange, na którym się wzorowałem w tej sprawie wie co robi, bo jest nieporównywalnie większy od Forbota Świetny artykuł o zadawaniu pytań linkuje w swoim podpisie. Mowa o tekście przetłumaczonym przez @deshipu. Tekst jest świetnie merytorycznie, ale obawiam się, że jego skuteczność nie jest wysoka. Ile osób przeczyta coś takiego przed zadaniem pytania? Niestety raczej mało. Tak, zdaje sobie sprawę, że jest to problemem i chcę to również rozwiązać. Ciągle zastanawiam się tylko nad formą. Na ten moment rozważam 3 rozwiązania: Krótkie wytyczne na temat sposobu zadawania pytania wraz z prośbą o opisanie swojego stanu wiedzy, które będą wyświetlane podczas zakładania tematów przez nowe osoby. Pole w profilu, w którym można określić swój stopień zaawansowania (już kiedyś proponował to @Elvis). Tutaj największą trudnością wydaje mi się jednak stworzenie dobrze opisanej skali i ewentualna podatność na efekt Dunninga-Krugera. Wprowadzenie formatek dla nowych tematów w działach, gdzie najczęściej pojawiają się pytania początkujących. To znaczy, że po rozpoczęciu tematu, w edytorze znajduje się już tekst typu: Nie jestem jednak przekonany do żadnej z tych wersji. Jeśli ktoś ma jakąś kolejną propozycję lub sugestie to chętnie poczytam
  12. 1 punkt
    Witam, jestem Jarek z poznania, moje zainteresowanie elektroniką wzięło się z popularności tej dyscypliny obecnie. w tej chwili przechodzę przez kurs elektroniki dla początkujących. Pozdrawiam wszystkich.
  13. 1 punkt
    Cześć, nie rozumiem, po co piszesz, że wszystko jest OK. Nic Ci nie działa prawidłowo - tak właśnie jak u Ciebie objawiają się błędy tego środowiska. pod Windowsem 10 Prawdopodobnie odpalasz wersję 64-bitową "Project Navigator ISE" - ta wersja nigdy nie działala mi poprawnie pod Windows10 . Zlokalizuj wersję 32-bitową (gdzieś w podkatalogu bin) i ją uruchom - prawdopodobnie nie będzie już tego błędu (zamykania się środowiska). Faktu, iż nie działa symulacja u Ciebie jestem prawie pewien (pewnie pomyliłeś ją z fazą syntezy i implementacji). Pisałeś, lub uruchamiałeś "test bench", żeby uruchomić symulację. Używaj tylko wersji 32-bitowej środowiska, bo tylko ona (w niepełnym zakresie) działa dla Windows10 prawidłowo. Najlepiej zainstalować ISE pod Linuxem (tam działa to dobrze). Scieżka do 32-bitowego "Project Navigatora pod Windows10 to : Pozdrawiam BTW: do przejścia kursu FPGA Forbota na Elbercie na szczęście nie jest potrzebna dziłająca opcja symulacji.
  14. 1 punkt
    @Johny witamy na forum! Powodzenia w eksperymentach, w starszej elektronice faktycznie można znaleźć coś użytecznego. Sam pamiętam jak chodziłem do serwisu AGD, bo tam mieli sporo elektro-złomu ze starych telewizorów kineskopowych. @krizzu witamy na forum, jak masz już początkowe zainteresowanie to myślę, że nie będziesz miał problemów z realizacją zadań.
  15. 1 punkt
    Zasilacze tego typu są zwykle robione w ten sposób, że na wejściu masz typową przetwornicę AC/DC czyli: prostownik napięcia sieciowego z filtrami EMI, potem konwerter DC/DC z 320VDC na stabilizowane 5VDC do napędzania cyfrówki i przy okazji dostajesz gdzieś tam "bokiem" kilkanaście woltów DC (12-24V) z którego zasilana jest z kolei przetwornica DC/AC dla lamp pod ekranem LCD. I tyle. Najlepiej by było,gdyby to dodatkowe napięcie stałe było właśnie rzędu 10-12V bo wtedy podpinasz tam bezpośrednio akumulator i jedziesz. Bo przecież "cyfrowe" 5V to sam sobie z akumulatora zrobisz czymkolwiek. Na płytce widać zespół filtrów EMI tuż przy gnieździe sieciowym, potem prostownik, główny elektrolit, transformator przetwornicy, jej tranzystor i dioda i tam już masz 5V. No i spróbuj wyśledzić obwód z dodatkową diodą i elektrolitem zasilający układ blisko tego podłużnego transformatora robiącego 700VAC. Nie wiem dokładnie jakiej porady oczekujesz..
  16. 1 punkt
    Witam wszystkich, jestem Bartek, 25 letni tata. Dzięki złamanej nodze i cichej miłości do łączności, przyszło mi ostatnio podłączać CB samochodowe w domu. Okazało się to bardziej skomplikowane, niż myślałem (przeciwwaga anteny, stworzenie zasilacza do radia). Przy przeróbce zasilacza ATX jakoś tak zacząłem więcej czytać na temat prądu i koniec końców jestem posiadaczem zestawu elektronika. Dziś zaczynam działać, a w głowie już mam kilka projektów - na początek recykling starej elektroniki Pozdrawiam wszystkich
  17. 1 punkt
  18. 1 punkt
    kolejna aktualizacja do funkcji start extern volatile unsigned long timer0_millis; uint16_t ledCounter; uint8_t state; enum State {RESTART_TIME, ON_TIME, OFF_TIME, SET_TIME}; void setup() { Serial.begin(9600); DDRC = 15; // A0..A3 Output DDRB = 48; //D8...D11 INPUT, D12 and D13 Output PORTB = 15; //D8...D11 High impedance DDRD = 60; //D2...D5 OUTPUT PORTD = 192; //D6 D7 High impedance } void loop() { start(timeSet(1, 0, 0), 150, 150, 100); } void start(uint32_t wait, uint32_t onTime, uint32_t offTime, uint16_t counter) { static byte index = 0; byte pin[30] = {3, 4, 12, 2, 4, 13, 3, 2, 2, 4, 5, 13, 3, 5, 3, 5, 3, 4, 4, 3, 5, 3, 2, 3, 4, 2, 12, 12, 3, 2}; if (state == RESTART_TIME) { //Serial.println("start"); state = ON_TIME; timer0_millis = 0; } if (timer0_millis > wait && timer0_millis <= (onTime + wait) && state == ON_TIME && ledCounter <= (counter - 1)) { (pin[index] == 12 || pin[index] == 13) ? PORTB |= 1UL << pin[index] - 8 : PORTD |= 1UL << pin[index]; state = OFF_TIME; } if (timer0_millis >= (wait + onTime) && state == OFF_TIME) { if (timer0_millis < onTime + wait) return; Serial.println(timer0_millis); (pin[index] == 12 || pin[index] == 13) ? PORTB &= ~(1UL << (pin[index] - 8)) : PORTD &= ~(1UL << (pin[index])); ledCounter++; state = SET_TIME; } if (timer0_millis >= (onTime + offTime + wait) && state == SET_TIME) { if (timer0_millis < onTime + offTime + wait) return; Serial.println(timer0_millis); Serial.println(ledCounter); index++; if (index == 30) index = 0; state = ON_TIME; timer0_millis = wait; } } uint32_t timeSet(uint32_t s , uint32_t m , uint32_t h) { h = h * 1000 * 3600; m = m * 1000 * 60; s = s * 1000; return h + m + s; } Po n ilości prób zaobserwowałem że diody czasami potrafią zmieniać stany w, krótszym czasie niż zadany. W teorii wygląda to tak , że dioda zaświeca się następnie powinna zgasnąć i zaświecić się kolejna ale przy krótkich czasach np: 250/250ms on/off stanu niskiego prawie nie widać tak jakby odrazu zapalała się kolejna dioda. Aby zaobserwować jak to wygląda w terminalu trzeba w w/w kodzie skomentować lub usunąć return; wgrać szkic otworzyć terminal odczekać chwilę i sprawdzić wyniki. Poza liczbami, które oznaczają mignięcia diod zobaczymy też cyfry 1024 czy 1280 co oznacza , że w tym momencie stan niski był krótszy niż powinien. Debugera niestety nie mam więc jest dodatkowy if z return i w ten sposób działa to prawidłowo. Czasy on off są takie jak być powinny (czasem jest 1ms różnicy ale to mi nie przeszkadza). Jest dodatkowa funkcja do wprowadzania czasu timeSet() kolejno sekundy , minuty, godziny. Sprawdzałem z opóźnieniami 2-5 godzin (jest jakieś 2-5s opóźnienia).
  19. 1 punkt
    Strzelam, że nie uruchomiłeś timera: pewnie brakuje wywołania tej metody: start(), możesz to sprawdzić - czy timer działa prawidłowo za pomocą isValid(),.
  20. 1 punkt
    Cześć @szeryf, jak zobaczysz sobie tutaj: https://doc.qt.io/qt-5/qtimer.html#accuracy-and-timer-resolution: "The accuracy of timers depends on the underlying operating system and hardware. " "All timer types may time out later than expected if the system is busy or unable to provide the requested accuracy. In such a case of timeout overrun, Qt will emit timeout() only once, even if multiple timeouts have expired, and then will resume the original interval" To dowiesz się, że wskazania mogą oscylować, ale generalnie powinny być akceptowalne w dużej mierze aplikacji używających QTimer, natomiast myślę, że problem u Ciebie nie występuje w dokładności QTimer, tylko podejściu, które zastosowałeś: stosujesz interwał = 1ms, czyli praktycznie wykorzystujesz QTimer do granicy możliwości, co może skutkować tym, że będziesz tracił wystąpienia sygnalizowane przez timeout() - czyli timer pokaże mniejszą niż zmierzoną długość czasu niż ta którą zmierzyłeś telefonem. Wydaje mi się że do tego zadania zdecydowanie lepiej nadaje się QElapsedTimer, który działa dokładnie tak jak chcesz - czyli stoper. QElapsedTimer możesz użyć do zmierzenia czasu, a QTimer do cyklicznego (np. co 60Hz) odświeżania interfejsu. Wtedy powinieneś uzyskać dokładnie to co chcesz.
  21. 1 punkt
    Słusznie, Addamsów. Człowiek to oglądał a nie czytał. Dziękuje za uwagę. Już poprawiam. Co z Rąsią? Na razie dostała oczka z czujnika ultradźwiękowego - w formie eksperymentu - bez przewidywanego dalszego wykorzystania. W przyszłym tygodniu pierwsze prace ze wzmacniaczem elektromiograficznym z suchymi elektrodami. Na razie tylko jeden kanał, bo zabawa dość kosztowna. I solidne (waży 1,5 kg) ramię o sześciu stopniach swobody. Oczywiście chińskie. Potem sterowanie głosowe i nauka w języku polskim. Myślę, że starczy na jakieś pół roku zabawy. Na koniec współpraca z osobą, której będzie pomagać...
  22. 1 punkt
    LM358/324 zadziała do -300mV przy zasilaniu tylko napięciem dodatnim. Inna opcja wygenerować napięcie ujemne np ILC7660.
  23. 1 punkt
    Witam serdecznie. Od dziś jestem w Wami na forum. Zaczynam swoją przygodę z elektroniką, choć nie zupełnie pierwszy raz. W latach 80-tych trochę się tym bawiłem, ale to były czasy tranzystorów i oporników. Trochę mnie to zniechęciło, bo trudno było zdobyć części, a niektóre w sklepach już były wadliwe i zmontowane układy często nie działały. Na horyzoncie pojawiły się komputery, więc od elektroniki przeszedłem do informatyki. Pisanie programów było dla mnie ciekawsze. Niedawno natrafiłem na Arduino. Tutaj programowanie płynnie wplata się w świat cyfrowej elektroniki. I tak historia zatacza powoli koło. Zobaczymy :)
  24. 1 punkt
    @Gieneq Chciałbym żeby efekt końcowy był elegancki, żebym mógł zaprezentować moje oprogramowanie klientowi. Myślałem o tym, żeby poszukać stackowanej obudowy i w pionie mieć 4 malinki, np coś takiego Stackowalna obudowa z wiatrakami Potem całość razem z zasilaczem w jakiejś obudowie, ew. zasilacz w osobnej obudowie dla bezpieczeńśtwa, żeby się nie pokopać prądem. Dziękuję bardzo za sugestię z pleksi, jak już złożę zestaw to dokładnie pomierzę całość i zamówię "szafkę" z pleksi na wymiar.
  25. 1 punkt
    Pierwsze pytanie - czy używasz płytki Nucelo-103rb, czy czegoś innego? Chodzi mi głównie o to czy używane piny są wolne. Druga sprawa - próbowałeś testować diodą led lub multimetrem? Warto zacząć od czegoś prostego, upewnić się że sterowanie pinem działa i dopiero wtedy podłączyć silnik. I ostatnie pytanie - testowałem na Nucleo103rb kod sterujący PA15, inicjalizacja taka jak u Ciebie, tylko z dwoma linijkami o których pisałem wcześniej - mógłbyś sprawdzić czy taki program działa poprawnie? Jeszcze jedno pytanie - napisałeś: "wstawiając breakpointy i przeglądając ODR można zauważyć, że stan na pinie zmienia się," - jak rozumiem to znaczy że zmienia się wartość w rejestrze ODR, co w sumie jest oczywiste - ale czy testowałeś stan pinu?
  26. 1 punkt
    My sie z kołem SKORP wybieramy ale jako uczestnicy więc na transmisje raczej nie bedziemy mieć czasu, chyba że coś się zmieni to damy znać ;)
  27. 1 punkt
    Napisałem reklamacje, bez problemu mi ją przyjęto i sklep wysłał mi nowe serwo, teraz wszystko śmiga jak powinno.
  28. 1 punkt
    Dzień dobry, Jestem tylko użytkownikiem elektroniki. Zainteresowało mnie konkretne rozwiązanie opisane na portalu forbot.pl . Mam nadzieję, na praktyczne zastosowanie takiego układu w mojej firmie. Pozdrawiam, Lubomir
  29. 1 punkt
    funkcja void loop() nigdy się nie kończy zobacz: C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\main.cpp więc po co ten return; ?
  30. 1 punkt
    Tak wyjaśniona i już wiemy że tak jest bezpiecznie Sprawdziłem temperaturę i bez obciążenia jest około 43stC a przy obciążeniu około 50stC gdy odłączę wentylatorek (podłączony do 3v3) to temp wzrasta do 70stC Dodam że przyklejone mam 3 radiatorki
  31. 1 punkt
    Pierwsze spotkanie już 8 października o 18:00 w Sztuce Wyboru ul. Słowackiego 19 Gdańsk. Link do wydarzenia: https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/264532531/ Pierwsze spotkanie będzie skupione wokół systemów safety-critical. Adam Lasota opowie nam o Model Based Design, czyli technice tworzenia oprogramowania za pomocą diagramów, z których następnie generowany jest kod. Taki sposób tworzenia kodu jest popularny między innymi w lotnictwie. Adam na co dzień pracuje z użyciem Model Based Design i podzieli się z nami swoimi wrażeniami na temat tej techniki. Następnie Piotr Strzałkowski zachęci Was do zapoznania się z językiem Ada. Jest to język stworzony na potrzeby amerykańskiego wojska i jest uznawany za najbezpieczniejszy język programowania. Ada jest językiem wysokiego poziomu zawierającym klasy, czy typy generyczne a jednocześnie pozwala na tworzenie niskopoziomowego kodu do obsługi peryferiów. Do tego posiada bardzo zaawansowany system typów i różne zabezpieczenia nie pozwalające na przykład na wyjście poza indeks tablicy, czy dereferencję null pointera. Piotr opowie jak Ada mogłaby ułatwić życie programisty embedded przyzwyczajonego do języka C. Meetup jest również świetną okazją, żeby porozmawiać z osobami z okolic Trójmiasta zajmującymi się podobną tematyką i wymienić się doświadczeniami. Harmonogram: 18.00 Adam Lasota - "Model Based Design" 18.50 Przerwa na pizzę 19.10 Piotr Strzałkowski - "Wprowadzenie do Ady"
  32. 1 punkt
    Dzień dobry mam 19lat i zainteresowała mnie elektronika/elektryka Szukajac informacji w internecie trafiłem na bloga i po przeczytaniu kilku artykułów od razu kupiłem zestawy by wesprzeć autora
  33. 1 punkt
    @ethanak No właśnie mam problem z przełożeniem tego co pojawia się np. na ekranie komputera gdy piszę program, a z tym co wyświetla port szeregowy. Gdy piszę w np. php print('coś tam'); otrzymuję pojedynczy wiersz na wyjściu z tym tekstem i tyle. Gdy piszę w ArduinoC Serial.print("Klawisz"); Serial.println(nowy); w porcie szeregowym mam efekt przewijania się wielu wierszy Klawisz i sporadycznie gdy wduszę jakiś klawisz to wyświetli się jaki. I to nie jest to co chcę uzyskać. Efekt który chcę uzyskać to coś podobne do tego co mam w php. Wyświetli się aktualny klawisz i nie ma tej całej sekwencji "Klawisz". Docelowy efekt ma być taki że gdy naciskam klawisz pojawia się dźwięk o zdefiniowanych parametrach (wysokości i długość) i najpierw pojawia się dany znak, zamieniany po sekundzie na # lub *. Po prostu ma być podgląd tego co się nacisnęło bez zbyt długiego czasu na zobaczenie przez osoby postronne. Docelowo z tej całej funckjonalności zrobić funkcję która będzie zwracać prawdę lub fałsz i na bazie tego system albo włącza alarm albo rozbraja się.
  34. 1 punkt
    Napisz może dokładnie co chciałeś osiągnąć i dlaczego to co jest nie działa zgodnie z oczekiwaniem ( co to znaczy "przewija się sekwencja"). Tak przy okazji pomyśl o rezygnacji ze String na rzecz zmiennych typu char i tablic - pamięć w Arduino nie jest z gumy i za chwilę może jej zabraknąć! Poczytaj o niebezpieczeństwach używania malloc() i free() - klasa String jest zaimplementowana za pomocą tych funkcji.
  35. 1 punkt
    Stąd (cytując opis na Botlandzie):
  36. 1 punkt
    No to troszkę inaczej, czyli bliżej rzeczywistości. Plik dw.cpp identyczny w obu przypadkach: void digitalWrite(int pin, int value) { volatile int a = pin; volatile int b = value; } Zestaw pierwszy: plik sc1.cpp: #include "testy1.h" const int PIN = 7; int main(void) { pinOn(); } plik sd1.cpp: #include "testy1.h" void pinOn(void) { digitalWrite(PIN,1); } plik testy1.h: extern void pinOn(void); extern const int PIN; extern void digitalWrite(int, int); Zestaw drugi: plik sc2.cpp: #include "testy2.h" int main(void) { pinOn(); } plik sd2.cpp: #include "testy2.h" void pinOn(void) { digitalWrite(PIN,1); } plik testy2.h: extern void pinOn(void); #define PIN 7 extern void digitalWrite(int, int); I teraz kompilacja: $ avr-gcc -Os -o s1.elf sc1.cpp sd1.cpp dw.cpp $ avr-gcc -Os -o s2.elf sc2.cpp sd2.cpp dw.cpp $ avr-size s1.elf text data bss dec hex filename 80 2 0 82 52 s1.elf $ avr-size s2.elf text data bss dec hex filename 52 0 0 52 34 s2.elf Jak widać, w przypadku const kod jest dłuższy, a w sekcji data mamy naszego pina Przypadek ze static pominąłem.
  37. 1 punkt
  38. 1 punkt
    Co możemy szybko i łatwo sprawdzić porównując wynikowy assembler obu wersji: https://godbolt.org/z/AzPxGk który dla obu wersji jest identyczny pod AVR gcc 5.4.0 (różni się jedynie wartością, którą reprezentuje `PIN` w celu odróżnienia wersji).
  39. 1 punkt
    Możesz jeszcze spróbować zmniejszyć w programie prędkość I2C.
  40. 1 punkt
    @espiridion ten interfejs nie jest raczej dedykowany do komunikacji na dalekie odległości, ale jest szansa, że zadziała. Wiele zależy od samego przewodu oraz warunków w jakich wykonujesz te testy (kwestia zakłóceń). Zerknij na ten artykuł: https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introduction-to-i2c-over-long-wires/
  41. 1 punkt
    analogRead tak w kwestii formalnej.
  42. 1 punkt
    A ile prądu pobierać będzie ten robot? Jaki jest przekrój przewodu w skrętce? Ile amper można puścić taką skrętką? Tu na razie nie ma (jeszcze) żadnej elektroniki tylko proste liczenie prądów. Poza tym prąd do zasilania robota (przy zasilaniu kablem) nie pobierasz z żadnego PC, tylko z porządnego akumulatora (np. takiego). Akumulatory w robocie i tak muszą przez chwilę zasilać silniki czyli zasilanie z nich samej elektroniki jest bezcelowe (robot w sytuacji awaryjnej ma się wynurzyć a nie osiąść na dnie i zastanawiać się, dlaczego konstruktorowi nie wpadło do głowy, że silniki bez prądu dziwnie słabo działają). Ogólnie PoE to fajna sprawa, ale do zasilania trzech silników jakoś niespecjalnie się nadaje
  43. 1 punkt
    Kamerę możesz ewentualnie wstawić poza RPi. Są takie małe kamerki z kartą SD i wyjściem video. Testowaliśmy transmisję na 20m po kablu i jest to realne, a obraz zawsze będziesz miał nagrany. Kamerki takie kosztują od 50 do 200zł. Jeżeli nie chcesz ethernetu to kup moduły UART-CAN i też da radę. Ekranowany kabel i nie powinno być zakłóceń. do sterowania arduino w łodzi, arduino w pilocie. Na ekranie z wejściem analogowym będziesz miał podgląd z kamery. Kiedyś dla testu podłączyłem 2 Arduina przez UART po 20m kablu i też działało. Ale CAN będzie dużo lepszy.
  44. 1 punkt
    Oj, po takim potraktowaniu autor wątku chyba już się nie pojawi:(
  45. 1 punkt
    A ja się pochwalę tym co zrobiłem. Program powinien działać (chyba, nie mam jak sprawdzić) w zasadzie z dowolną ilością LED pod warunkiem zdefiniowania tej ilości w "LEDcount". Pewnie jest sporo błędów ale nie zajmuje się programowaniem na co dzień. Inspiracja: kaukaskie wieżowce #include <Adafruit_NeoPixel.h> #define LEDcount 8 #define background 10 #define diff 150 #define maximum 255 Adafruit_NeoPixel RGBstrip= Adafruit_NeoPixel(LEDcount, A0, NEO_GRB + NEO_KHZ800); #define opoznienie 100 int i = 0; int j = 0; void setup() { RGBstrip.begin(); for(i = 0; i < LEDcount; i++){ RGBstrip.setPixelColor(i, RGBstrip.Color(0, 0, background)); } RGBstrip.show(); } void loop() { for(int i = 0; i < LEDcount; i++){ for(int j = 0; j < 255; j++){ if(i == 0){ RGBstrip.setPixelColor(i, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, maximum))); RGBstrip.setPixelColor(i+1, RGBstrip.Color(0, 0, map(j, 0, 254, background, maximum - diff))); RGBstrip.setPixelColor(LEDcount-1, RGBstrip.Color(0, 0, map(j, 0, 254, maximum, maximum - diff))); RGBstrip.setPixelColor(LEDcount-2, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, background))); } else if(i == 1){ RGBstrip.setPixelColor(i, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, maximum))); RGBstrip.setPixelColor(i+1, RGBstrip.Color(0, 0, map(j, 0, 254, background, maximum - diff))); RGBstrip.setPixelColor(i-1, RGBstrip.Color(0, 0, map(j, 0, 254, maximum, maximum - diff))); RGBstrip.setPixelColor(LEDcount-1, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, background))); } else if((i > 1) && (i < (LEDcount-2))){ RGBstrip.setPixelColor(i, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, maximum))); RGBstrip.setPixelColor(i+1, RGBstrip.Color(0, 0, map(j, 0, 254, background, maximum - diff))); RGBstrip.setPixelColor(i-1, RGBstrip.Color(0, 0, map(j, 0, 254, maximum, maximum - diff))); RGBstrip.setPixelColor(i-2, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, background))); } else if(i == LEDcount - 2){ RGBstrip.setPixelColor(i, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, maximum))); RGBstrip.setPixelColor(i+1, RGBstrip.Color(0, 0, map(j, 0, 254, background, maximum - diff))); RGBstrip.setPixelColor(i-1, RGBstrip.Color(0, 0, map(j, 0, 254, maximum, maximum - diff))); RGBstrip.setPixelColor(i-2, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, background))); } else if(i == LEDcount - 1){ RGBstrip.setPixelColor(i, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, maximum))); RGBstrip.setPixelColor(0, RGBstrip.Color(0, 0, map(j, 0, 254, background, maximum - diff))); RGBstrip.setPixelColor(i-1, RGBstrip.Color(0, 0, map(j, 0, 254, maximum, maximum - diff))); RGBstrip.setPixelColor(i-2, RGBstrip.Color(0, 0, map(j, 0, 254, maximum - diff, background))); } RGBstrip.show(); delayMicroseconds(opoznienie); } } }
  46. 1 punkt
    Jak już ten starty temat został przywołany to warto chyba dodać w tej chwili do tej listy JLCPCB i PCBWay
  47. 1 punkt
    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
  48. 1 punkt
    Urządzenia nie powinny być bardziej skomplikowane niż to czego wymaga spełnianie założeń konstrukcyjnych. Generalnie w zasilaniu słonecznym zależy nam na maksymalizacji sprawności przetwarzania energii od samego wejścia do wyjścia bo energia słoneczna jest.. droga. Z drugiej strony takie jednostkowe układziki jak Twój mogą trochę odpuścić, bo jeśli nawet gdzieś tam marnujesz zbyt wiele, to najwyżej weźmiesz trochę większy/droższy panel i całość się zepnie (a przynajmniej własne zadowolenie będzie zachowane). W długiej serii produkcyjnej to nie przejdzie, bo czasem te kilka zł czy dolarów za lepszy panel czy elektronikę stanowi o być albo nie być projektu. Masz więc jakiś panel, ładowarkę, akumulator i odbiornik. Możesz zacząć od ogólnego bilansu energii: W Polsce zwykle przyjmuje się współczynnik 900 a Twoje ogniwo dające 5.5V/120mA ma moc szczytową ok. 0.6W. W ciągu roku dostaniesz z niego zatem ok. 590Wh. Odbiornik potrzebuje 20mA (tutaj nie można posługiwać się prądami tylko mocami) na napięciu akumulatora. Stabilizator jest tam liniowy więc żadnej zmiany prądu nie będzie i zysku z wyższego napięcia też nie. Zakładając średnie napięcie akumulatora 3.7V mamy 74mWh w ciągu godziny i prawie 650Wh w ciągu roku. Nawet gdybyś zrobił idealny transfer energii z panelu do procka, to i tak nie starczy A przecież dodatkowo: a. Ładowarka jest liniowa więc najgorszy możliwy przypadek dla panelu. b. Moc panelu może być przeszacowana, bo to jednak chińszczyzna jest. Co więcej, nie wiemy czy te 5.5V/120mA to punkt mocy maksymalnej czy po prostu parametry maksymalne mierzone osobno, a to nie to samo. c. Nie uwzględniliśmy wahań nasłonecznienia między zimą a latem. Bilans został policzony tak, jakby przez cały rok było trak samo a przecież zimą "dziury" w bezpośrednim oświetleniu mogą być dłuższe, nawet wielodniowe. Mały akumulator może nie zapewnić ciągłości pracy urządzenia w takich warunkach. Wielkość 14500 to jednak tylko jakieś 800mAh a to starczy może na jedną dobę pracy urządzenia bo musisz mieć na wejściu zasilania min. 3.5V a to nie jest wyładowanie do końca. Moje wnioski: a. Większy czyli mocniejszy panel albo dwa takie równolegle. Ta dioda na wejściu jest oczywiście bez sensu, wywal ją. b. Ładowarka lepiej wykorzystująca cechy paneli słonecznych, ale to tylko wtedy gdy wielkość baterii słonecznej będzie "na styk". Zawsze można "z ciekawości" zbudować coś fajniejszego (MPPT?) np. na SPV1040. c. Moim zdaniem dopiero dwa równoległe 18650 mające w sumie ponad 5Ah dawałyby komfort i pozwalały przetrwać ponad tydzień bez słońca. d. Koniecznie poczytaj o cechach baterii słonecznych, bo nie są podobne ani do baterii chemicznych, ani do typowych zasilaczy ani do akumulatorów.
  49. -1 punktów
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...