Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 4 punkty
    Sprzęt Lubię stary sprzęt, nie tylko komputerowy. Zdobyłem starą tarczę telefoniczną, wyczyściłem styki i uformowałem różne elementy które się pogięły, a następnie postanowiłem zrobić z tego klawiaturę. Przykleiłem na spodzie tarczy Seeeduino Xiao (taśmą dwustronną), wylutowałem oryginalny sznur i dodałem trzy przewody, starając się zresztą użyć tych samych kolorów, które były tam oryginalnie, chociaż wątpię czy jest na to jakiś ustalony standard. Sprzęt nie był wygodny do trzymania i łatwo było przypadkowo palcem zablokować mechanizm, więc złożyłem małe pudełko ze sklejki. (Na wszelki wypadek wyjaśnię jak się używa takiej tarczy. Żeby wybrać jakąś cyfrę, wkłada się palec w odpowiednią dziurę w tarczy, a następnie obraca tarczę w kierunku ruchu wskazówek zegara aż do momentu gdy palec zatrzyma się na tej metalowej blaszce. Tarcza, puszczona, wraca do położenia początkowego, w międzyczasie wykręcając numer w trybie pulsowym, czyli rozwierając i zwierając przewody, którymi telefon połączony jest z centralą.) Oprogramowanie Ustaliłem eksperymentalnie (z pomocą mojej pokazywaczki Hantek, która do tego celu była w sam raz) jakie sygnały nadaje tarcza. Otóż normalnie pin czerwony nie jest zwarty z żółtym, ale jeśli tarcza jest przynajmniej trochę obrócona, to się zwierają. Natomiast pin zielony jest normalnie zwarty z czerwonym, natomiast w czasie gdy tarcza się cofa, to to coś na wierzchu tej mniejszej zębatki rozwiera je i zwiera. Tych "pulsów" jest mianowicie tyle, z jakiej cyfry tarcza wraca (10 dla cyfry 0). Odczytanie wybranej na tarczy cyfry jest więc dość proste, na przykład tak: void setup() { pinMode(PIN_YELLOW,INPUT_PULLUP); pinMode(PIN_GREEN,INPUT_PULLUP); pinMode(PIN_RED,OUTPUT); digitalWrite(PIN_RED,LOW); } void dialledDigit(int d){ // Cyfra wybrana } void loop() { if(digitalRead(PIN_YELLOW)==LOW){ int p=0; byte prevG=LOW; delay(20); while(digitalRead(PIN_YELLOW)==LOW){ byte g=digitalRead(PIN_GREEN); if(g>prevG) p++; prevG=g; digitalWrite(LED_BUILTIN,!g); delay(10); } digitalWrite(LED_BUILTIN,HIGH); if(p) dialledDigit(p%10); } delay(5); } Najprostsze co można dalej zrobić, to użyć funkcji z Keyboard.h i wysyłać wybrane cyfry, ale taka klawiatura potrafi wpisywać tylko cyfry, a to trochę mało. Dlatego doimplementowałem tryb ASCII, który działa tak, że wybiera się kolejne cyfry kodu ASCII znaku, który chce się wpisać. Czyli żeby napisać 'A' (=65), trzeba wybrać 6 a potem 5. Większość kodów dwucyfrowych łatwo odróżnić od trzycyfrowych - wiadomo, że 65 nie jest początkiem trzycyfrowej liczby, bo maksymalna wartość kodu to 255. Natomiast kody poniżej 26 trzeba poprzedzić zerem. To jednak nadal za mało, bo chciałem również móc przytrzymywać klawisze, na przykład do tego, żeby pisać polskie litery z prawym altem, a także do innych operacji na przykład na tekście. Dlatego dodałem jeszcze następujące funkcje: Kod poprzedzony przez 00 oznacza, że klawisz należy przytrzymać. Gdy później wybrany zostanie dowolny kod bez 00, to ten klawisz zostanie puszczony. Kod poprzedzony przez 0000 oznacza, że klawisz należy przytrzymać, i trzymać tak długo, aż ponownie zostanie wybrany jego kod. Tryby zmienia się generując większą niż 10 liczbę pulsów. Żeby to osiągnąć, należy naciągnąć tarczę, potem pozwolić jej się cofnąć, ale tylko częściowo, i naciągnąć ponownie. W ten sposób liczba pulsów w czasie, gdy pin czerwony jest zwarty z żółtym, może być dowolnie duża. Efekt (oglądać z włączonymi napisami!): Łatwiej mi było nagrać klawiaturę podłączoną do telefonu niż do komputera, działa oczywiście tak samo. Można też oczywiście użyć tarczy do... wybierania numeru, wystarczy uruchomić aplikację telefonu Możliwe zastosowania projektu No cóż... Jak się można domyślić, ta klawiatura nie jest specjalnie ergonomiczna i nie ma prawdziwego zastosowania. Natomiast można by było wykorzystać taką tarczę jako część większego projektu, na przykład zamka szyfrowego.
  2. 3 punkty
    Witam wszystkich! Około rok temu, w oczekiwaniu na coroczny konkurs techniczny organizowany w mojej szkole postanowiłem wykonać robotyczne ramię sterowanie kontrolerem w formie rękawicy. Ramię miało powtarzać ruchy dłoni oraz nadgarstka w czasie rzeczywistym. Głównym celem było stworzenie działającego prototypu dzięki któremu zwiększę swoją wiedzę w dziedzinie elektroniki, robotyki oraz programowania. Ramię Projektowanie Zabrałem się więc za projekt. Na samym początku rysowałem oraz testowałem różne konstrukcje przekazania momentu do odpowiednich stawów aż zdecydowałem się na linki w pancerzach. W mojej opinii jest to najlepsze rozwiązanie w konstrukcjach amatorskich z ograniczonym budżetem. Serwomechanizmy TowerPro SG90 wymieszane ze swoimi klonami, plecionka wędkarska 0.23mm, oraz wężyki silikonowe 3mm/1mm powinny załatwić sprawę. Powrót określonej części palca realizowany za pomocą gumek recepturek . Przeszedłem więc do programu fusion 360 i tak prezentują się efekty mojej pracy. Składanie Po otrzymaniu przesyłki z serwami od naszych wschodnich kolegów przystąpiłem do drukowania poszczególnych części projektu. Wszystkie elementy drukowałem na delikatnie zmodyfikowanym enderze 3 z PLA ora PETG. Serwa zostały przykręcone oraz przyklejone na klej cyjanoakrylowy. następnie przystąpiłem do przedziewania wężyków silikonowych i podklejania linek do odpowiedniej części dłoni. Szybko okazało się że wężyk, który zamówiłem kompletnie nie nadaje się do takiego zastosowania ze względu na duże tarcie oraz małą sztywność powodującą ściskanie się wężyka zamiast zginania palca w odpowiedzi na ciągnięcie linki przez serwo. Dlatego aby konstrukcja działała chociaż trochę lepiej owinąłem wszystkie wężyki koszulkami termokurczliwymi co w większości pozwoliło pozbyć się problemu ściskania. Jednakże dodało to dodatkowy milimetr średnicy każdemu z nich. Coś za coś. Zostało tylko dodać gumki i cała konstrukcja mechaniczna skończona. Kontroler Jako czujniki zgięcia zastosowałem potencjometry. Początkowo miały to być zwyczajne montażowe jednak niezliczone wady tego rozwiązania ujawniły się natychmiast po złożeniu pierwszego prototypu. W poszukiwaniu innej opcji trafiłem w Internecie na podobną konstrukcję również wykorzystującą potencjometry jednakże z otworem umożliwiającym przedzianie przez nie wału. Zakupiłem więc wystarczającą ilość sztuk i podczas oczekiwania na przesyłkę zaprojektowałem naprędce projekt drugiej rękawicy który okazał się finalnym. Dodatkowo do podłączenia potencjometrów użyłem wyjątkowo giętkich przewodów odpornych na wielokrotne zginanie( skrętka nie poradziła sobie w tej roli). Elektronika Mózgiem całego układu jest atmega 8 , otoczona elementami pasywnymi niezbędnymi do jej właściwego działania oraz do właściwego działania przetwornika ADC. Płytkę zaprojektowałem w programie Eagle, a wykonałem na zrobionym samodzielnie ploterze wykorzystując czarny pisak permanentny laminat zamiast kartki. Po kąpieli w wytrawiaczu płytka była gotowa do montażu. Oczywiście nie obyło się bez błędów wynikających z mojego małego doświadczenia oraz zwyczajnej nieuwagi. Drugim niezwykle ważnym układem był multiplekser 16 kanałowy wykonany z trzech multiplekserów 8 kanałowych. Takie rozwiązanie było zdecydowanie tańsze oraz niemiałem żadnych problemów z dostępnością części. Ponownie odpaliłem Eagle-a i w ruch ruszył mój ploter. Pierwsza płytka wykonana na elementach SMD okazała się całkowitą porażką natomiast druga na THT wyszła dokładnie tak jak powinna. Starałem się aby w całej części elektronicznej projektu jak najmniej elementów było lutowane "na stałe". Dlatego używałem złączek IDC, ARC oraz oczywiście goldpinów. Dzięki temu całość uzyskała budowę modułową niezwykle ułatwiającą przenoszenie oraz wszelakie naprawy. Program Program został napisany w języku C na mikrokontrolery AVR w środowisku Eclipse. Gdyby nie książka: " Mikrokontrolery AVR - podstawy programowania" Pana Mirosława Kardasia nie sądzę aby udało by mi się nauczyć się programować AVR-y oraz napisać mój program w tak krótkim czasie. Program jest niezwykle prosty. Co 20 ms czyli z częstotliwością odświeżania właściwą dla serw SG90 przestawiane są multipleksery za pomocą odpowiednich bitów, a wartość odczytana z potencjometru przez przetwornik ADC jest zamieniana funkcją map()( przekopiowaną z biblioteki arduino) na wartości odpowiadające odpowiedniemu wypełnieniu sygnału PWM. Dzieje się to ze względu na właściwość użytych przeze mnie serwomechanizmów. Przy odpowiedniej wartości wypełnienia PWM przyjmują one odpowiednią pozycję( w moim przypadku 0 stopni to około 1ms wypełnienia natomiast 180 stopni to około 2ms wypełnienia). Następnie 16 programowo generowanych kanałów PWM przyjmuje przekonwertowane dane i wysyła je złączem IDC na serwomechanizmy. Lista części: Serwomechanizmy SG90(klony + oryginalne) - ok. 80zł Plecionka, wężyk + rurka termokurczliwa- ok. 60zł Potencjometry APC ( z otworem ) - ok.20 zł Atmega 8 , złączki, elementy pasywne- ok.30zł Multipleksery CD4051BE - ok.6 zł Koszty druku( filament + prąd)- ok.40zł Wady: Konstrukcja zawiera ich bardzo wiele : mała sztywność całego układu złe wężyki ( zbyt wiotkie oraz zbyt grube) nieoryginalne serwa mające ogromne problemy właściwie ze wszystkim nieprzemyślana konstrukcja dłoni (zbyt wiele kleju zbyt mało połączeń rozłącznych) gumki zamiast sprężyn jako powrót po ściśnięciu brak prawidłowej filtracji zasilania!!! niedziałający nadgarstek(spowodowany przez: brak pinów na mikrokontrolerze, brak czasu , za słabe serwa , zbyt mało miejsca na prawidłowe działanie, nieprzemyślana budowa itp. Podsumowanie Jestem niezwykle zadowolony z całokształtu mojej pracy. Mimo wielu błędów( a raczej dzięki nim) nauczyłem się bardzo bardzo wiele. Od programowania, projektowania, trochę mechaniki oraz wiele więcej. Jeśli mógłbym doradzić coś osobą początkującym takim jak ja chcącym wykonać podobną konstrukcję to: proszę was kupcie oryginalne serwa! Mimo ich 3 razy większego kosztu działają nieporównywalnie lepiej do chińskich odpowiedników a ich właściwości także są o wiele lepsze. Na swoim przykładzie przekonałem się że niema czegoś takiego jak za trudny projekt jest tylko za mało czasu i pieniędzy. Wszystkiego da się nauczyć w trakcie pracy jednakże będzie to skutkować błędami tak jak w moim przypadku. Bogatszy w doświadczenie zacząłem już tworzyć drugi projekt ręki , która to min. będzie realizowała ruch palców w bok. Pozdrawiam wszystkich serdecznie i dziękuję za uwagę!
  3. 2 punkty
    Od dłuższego czasu chciałem stworzyć działającego robota Micromouse, a jednocześnie chciałem nauczyć się obsługiwać inne mikrokontrolery niż Arduino. Idealna okazja spełnienia obu tych rzeczy nadeszła gdy wszedłem w posiadanie płytki STM32F429I-DISC1. Tak o to rozpocząłem projekt o zaskakującej nazwie "Micromouse Robot". KONSTRUKCJA ROBOTA Komponenty, które postanowiłem wykorzystać w robocie to: Mikrokontroler STM32F429I-DISC1 Czujniki odległości (odbiciowe) skonstruowane z pary: dioda IR SFH4550 i fototranzystor SFH-313FA Silniki DC FIT0450 wraz z enkoderami magnetycznymi SJ01 Sterownik silników L298N Moduł bluetooth HC-06 Koła DFRobot Na samym początku zaplanowałem ogólny schemat robota: Na podstawie schematu ogólnego stworzyłem schemat elektroniczny przy użyciu programu KiCad: Następnie przyszedł czas na zlutowanie potrzebnych układów, w pierwszej kolejności był to moduł z czujnikami - zdecydowałem się na prostopadłe rozstawienie czujników, dwie pary wykrywające przeszkody po bokach oraz dwie pary wykrywające ścianę na wprost dzięki czemu możliwe będzie wykorzystanie ich odczytów do korekcji orientacji robota (oba przednie czujniki powinny odczytywać tą samą odległość od ściany). Dodatkowo zlutowałem pomocniczy układ z przełącznikiem i stabilizatorem step-down (gdyż zasilanie, którego użyłem dochodziło do 8V przy pełnym naładowaniu, a płytka potrzebowała 5V). Dzięki niemu miałem łatwy dostęp do pinów 5V lub 8V w zależności od potrzeby: W celu sprawdzenia działania stworzonego modułu czujników wykonałem testy przy użyciu programu STMStudio, które pozwoliło na łatwą wizualizację odczytów mikrokontrolera. Przeprowadzone testy potwierdziły poprawne działanie każdego z 4 czujników (niższa wartość oznacza przewodzenie fototranzystora w diodzie odbiorczej, tym samym sygnalizując, odbiór światła wysłanego przez diodę IR i odbitego od białej ściany - w skrócie, wykrycie przeszkody przez dany czujnik): Niestety w tym momencie okazało się, że pomieszczenie wszystkich elementów wraz z utrzymaniem sensownych rozmiarów robota będzie niemożliwe, dlatego po wykonaniu wielu pomiarów powstał model 3D przyszłej konstrukcji, na którego podstawie stworzona została rzeczywista konstrukcja stworzona z wyciętej płyty ebonitowej oraz drucianych podpór: Jak widać dzięki wymyślnej konstrukcji udało się pomieścić wszystkie elementy. Nadszedł czas na programowanie. OPROGRAMOWANIE ROBOTA Ze względu, że użyta płytka należała do rodziny STM32 to do pomocy w programowaniu użyłem środowiska STM32CubeIDE. Ponieważ jak już pisałem, była to moja pierwsza styczność z płytką inną niż Arduino, to bardzo pomocny okazał się Kurs STM32 F4 ze strony Forbota. Końcowo wykorzystałem: 4 piny ADC w celu odczytywania wartości z czujników odległości, 2 piny PWM w trybie countera w celu odczytywania wartości z enkoderów silników, 4 piny PWM do sterowania silnikami, oraz 2 piny USART w celu komunikacji z modułem bluetooth. Schemat blokowy przyszłego programu robota wygląda następująco: W tym momencie głównym zadaniem stało się zaimplementowanie najważniejszych funkcji, czyli: przeszukania labiryntu, znalezienia najkrótszej ścieżki i jej przejechania. Również w tym przypadku Forbot nie zawiódł i poratował mnie artykułem Roboty MicroMouse – 5 metod przeszukiwania labiryntu. To właśnie on skłonił mnie do wykorzystania metody propagacji fali. Wzorując się na przykładach z artykułu udało mi się stworzyć własną wersję algorytmu. W międzyczasie stworzyłem funkcje odpowiedzialne za ruch robota w przestrzeni. Odpowiednie przechowywanie aktualnej pozycji (x, y) oraz orientacji robota (północ, południe, zachód, wschód) pozwoliło na proste zaimplementowanie funkcji typu jedz(kierunek), która pozwalała na nawigację po labiryncie jak gdybyśmy patrzyli na niego z góry i zadawali, w którym kierunku ma przemieścić się robot. Dzięki temu możliwe stało się stworzenie symulacji, która pozwalałaby na przetestowanie działania zaimplementowanego algorytmu i funkcji ruchu. Tak też zrobiłem: Jak widać funkcje ruchu pozwalają na przemieszczanie się po poszczególnych polach labiryntu, natomiast algorytm bez problemu znajduje najkrótszą ścieżkę do celu. Przyszedł czas na rzeczywiste testy. W tym celu używając wyciętych kartonów oraz białych kartek A4 złożyłem własny labirynt (na zdjęciu jeszcze bez kartek), niestety ze względu na ograniczoną przestrzeń składał się on tylko z 4x4 pól, jednak nie był to zbyt duży problem, gdyż algorytm zdołał już udowodnić symulacyjnie, że działa także dla pełnowymiarowego labiryntu. Kolejnym wyzwaniem było zaprogramowanie ruchu robota po labiryncie. Z pomocą przyszły enkodery silników oraz czujniki na podstawie których napisałem proste regulatory PD. Pierwszy z nich używając enkoderów gwarantuje, że dystans pokonany przez oba silniki jest stały, natomiast drugi używający czujników zapewnia równy odstęp robota od wszystkich ścian labiryntu. Ich połączenie zapewnia sprawne przemieszczanie się robota po kolejnych polach labiryntu. PODSUMOWANIE Ostatecznemu wynikowi daleko do idealnych. Robot jest dosyć powolny i czasami gubi trasę - myślę, że jest to spowodowane w pewnym stopni jego wagą i wielkością użytych silników, co w połączeniu skutkuje brakiem możliwości wykonywania małych i precyzyjnych ruchów. Dodatkowo brakuje tu wielu usprawnień funkcji ruchu, np. nie zatrzymywanie się na każdym polu jeśli jedziemy prosto kilka razy z rządu. Pomimo to myślę, że robot wcale nie wypada tak źle jak na pierwszy tak duży projekt, przecież jednak jeździ i ma się dobrze. Dodatkowo ilości nowej wiedzy którą zdobyłem podczas jego tworzenia nie da się zastąpić. Ogólnie jestem zadowolony z efektu oraz całego projektu, jednak także świadomy jego niedoskonałości i możliwości poprawy w miarę zdobycia nowej wiedzy. Efekt końcowy (przeszukiwanie labiryntu oraz przejazd najkrótszą ścieżką przyspieszone prawie 5-krotnie) można obejrzeć na filmiku:
  4. 2 punkty
    Oczywiście, że się da. Można użyć UART-a lub USB. Należy tylko przy włączaniu zasilaniu ustawić odpowiednio piny BOOT. Nie orientuje się jak jest przy H7 ale przy STM32F207 wystarczy podczas włączania zasilania ustawić w stan wysoki pin BOOT0 np. switchem lub zworką. Nie wiem czy umożliwia takie programowanie STM32CubeIDE ale programem STM32CubeProgrammer na pewno to zrobisz.
  5. 2 punkty
    Cześć, mój kod do zadania 8.4. Działa ale może jakieś sugestie? // sterowanie silnikiem (diodami) void setup() { // silnik nr 1 pinMode(6, OUTPUT); // PWM pinMode(7, OUTPUT); // w lewo pinMode(8, OUTPUT); // w prawo // silnik nr 2 pinMode(3, OUTPUT); // w lewo pinMode(4, OUTPUT); // w prawo pinMode(5, OUTPUT); // PWM } int aktualnaPredkosc; // do zapisu osiagnietej predkosci - przyda sie przy hamowaniu int maksPredkosc = 255; // do ustawienia maksymalnej predkosci void loop() { startPrawo(5, 25); // start silnikow w prawo hamuj(5, 25); // hamowanie do zera delay(2000); startLewo(5, 25); //start silnikow w lewo hamuj(5, 25); // hamowanie do zera delay(2000); } void startPrawo(int zmianaPredkosci, int opoznienie) { // ustawienie wyjsc dla silnika nr 1: obroty w prawo digitalWrite(7, 0); digitalWrite(8, 1); // ustawienie wyjsc dla silnika nr 2: obroty w prawo digitalWrite(3, 0); digitalWrite(4, 1); for (int i = 0; i <= maksPredkosc; i += zmianaPredkosci) { analogWrite(6, i); // stopniowe zwiekszanie obrotow silnikna nr 1 analogWrite(5, i); // stopniowe zwiekszanie obrotow silnika nr 2 aktualnaPredkosc = i; // zapis predkosci - zostanie uzyty przy hamowaniu delay(opoznienie); } } void startLewo(int zmianaPredkosci, int opoznienie) { // ustawienie wyjsc dla silnika nr 1: obroty w lewo digitalWrite(8, 0); digitalWrite(7, 1); // ustawienie wyjsc dla silnika nr 2: obroty w lewo digitalWrite(4, 0); digitalWrite(3, 1); for (int i = 0; i < maksPredkosc; i += zmianaPredkosci) { analogWrite(6, i); // stopniowe zwiekszanie obrotow silnika nr 1 analogWrite(5, i); // stopniowe zwiekszanie obrotow silnika nr 2 aktualnaPredkosc = i; delay(opoznienie); } } void hamuj(int zmianaPredkosci, int opoznienie) { for (int i = aktualnaPredkosc; i >= 0; i -= zmianaPredkosci) { // hamujemy od aktualnej predkosci do zera analogWrite(6, i); // stopniowe zmniejszanie obrotow do zera (silnik nr 1) analogWrite(5, i); // stopniowe zmniejszanie obrotow do zera (silnik nr 2) delay(opoznienie); } } Film (polecam wyłączyć dźwięk, bo za oknem prace):
  6. 2 punkty
    Wszystkie masy muszą być ze sobą połączone, inaczej sygnały przesyłanie pomiędzy płytkami nie będą miały napięcia odniesienia.
  7. 2 punkty
    Wg google Twój dysk jest 2,5 calowy czyli od 0.7 do 3 watów + RPi 3b+ od 1.9-2.1 wata czyli czy zestaw będzie ciągną 3-5 watów. Przy założeniu że będzie pracował 24/7/360 to daje 8760 godzin (8760 x 3) / 1000 = 26,28 kW rocznie (8760 x 5) / 1000 = 43.8 kW rocznie i teraz zależy w dużej mierze gdzie mieszkasz - załóżmy że w warszawie i masz dostawcę prądu innogy który sprzedaje po 0,70zł za kWh 26,28 x 0,70 = 18,39 43.8 x 0,70 = 30.66 Czyli całkowity koszt będzie w granicach 20-30zł rok przy założeniu że żyjesz w stolicy, ale sam musisz sprawdzić ostatnią fakturę za prąd i cenę kWh u swojego dostawcy.
  8. 1 punkt
    Używam Atollica. Niemniej to kolejne wcielenie Eclipse tak jak CubeIDE. W Atollicu wymaga to dodania do opcji projektu dyrektywy generowania pliku HEX jak na lewym djęciu. Poniżej masz tą komendę. arm-atollic-eabi-objcopy.exe -O ihex "${BuildArtifactFileBaseName}.elf" "${BuildArtifactFileBaseName}.hex" Tworzy ona w katalogu DEBUG plik HEX. Ze względu na to, że Atollic nie jest połączony bezpośrednio ze środowiskiem CUBE dodałem sobie do EXTERNAL TOOLS możliwość programowania poprzez USB. Możliwość taką daje CubeMXProgrammer. Można go używać z linii komend. Jak dla mnie jest to bardzo wygodne. Na prawym zdjęciu masz przykład dla programowania z użyciem SWD bo w domu nie używam USB.
  9. 1 punkt
    OT: Odnoszę wrażenie, że kolega @MrH4ze pisze posty w swoim narodowym języku a potem jakimś marnym translatorem przekłada tekst na polski. To oczywiście nic złego, ale może choć trochę tłumaczy mnie z kompletnego niezrozumienia jego postów. Czy wam także powyższy opis dziwnie przypomina tłumaczenie instrukcji do chińskiej sokowirówki? A w temacie: czy kolega @rompaj już się zastanowił co właściwie chce zrobić? Czy filmik mamroczącego z offu hobbysty w czymś pomógł?
  10. 1 punkt
    @Kemer Próbowałeś znaleźć problem za pomocą debuggera? Jak mam nieoczekiwane crashe w programie to przyczyny szukam pod debuggerem, a gdy to zawiedzie to pod Valgrindem (pracujesz na RPi więc jest tam Linux, więc powinien być i Valgrind (po instalacji)). To co ja bym zrobił to: sprawdził pod debuggerem czy wskaźniki na obiekty, które tam dodajesz/używasz wskazują na poprawne miejsca w pamięci (strzelam, że to może być problemem), w Twoim przypadku raczej problem jest z obiektem graphicsView albo z obiektem sceny, który zwraca graphicsView->scene(), albo z obiektem item, który dodajesz do sceny (bo scena korzysta z tego obiektu, więc jak jest on niepoprawny to spowoduje to crash) - więc pod debuggerem sprawdziłbym dokładnie co tam siedzi, jak powyższe się nie uda, to można szukać problemów z pamięcią pod Valgrindem, jak powyższe się nie uda to uruchomiłbym ten sam kod na PC (tylko fajnie by było, gdyby tam był Linux) i na PC szukał problemu, Jak powyższe zawiedzie to stwórz "minimal example" które korzysta tylko z tego co u Ciebie nie działa - wcześniej sprawdź czy na pewno nie działa - i wrzuć kod tutaj, wtedy będziemy mogli odpalić to u siebie i poszukać problemu. Qt jest multiplatformowe, więc ten sam kod możesz uruchomić na PC - i jeśli tam występuje ten sam problem (to najprawdopodobniej Ty robisz coś źle) jak już rozwiążesz problem na PC to z dużym prawdopodobieństwem powinien działać też na RPi. Ale.. jeśli ten sam kod na PC będzie działał poprawnie, to znaczy że ten port (Qt na RPi) ma akurat jakieś błędy i wtedy raczej musimy szukać pomocy na forum Qt, Stackoverflow itp.
  11. 1 punkt
    Jest mój artykuł w dziale artykuły użytkowników Port USB i bootloader w STM32f1C8T6 a Windows 10 i ARDUINO IDE.Przeczytaj i wyciągnij wnioski. Nie wiem czy dla tego STM-a jest pliczek wsadowy obsługujący port USB ale to jest do sprwdzenia bo tych pliczków jest tam gdzieś dosyć dużo.
  12. 1 punkt
    Może zobacz Rtc by Makuna - bardzo fajnie udokumentowana z własnym WIKI
  13. 1 punkt
    @Wirgiliusz witam na forum i gratuluję ciekawej konstrukcji - opis został opublikowany, więc jest już publicznie widoczny
  14. 1 punkt
    Problem rozwiązany. Wpisujemy do terminala: sudo apt-get install qtmultimedia5-dev libqt5multimediawidgets5 libqt5multimedia5-plugins libqt5multimedia5
  15. 1 punkt
    @Kemer witam na forum Możesz przejrzeć kurs QT na blogu, może znajdziesz tam coś co Ci się przyda w tym przypadku. Jeżeli nie, to myślę że kolega @Matthew11 odpowie na każde pytanie dotyczące QT
  16. 1 punkt
    W trakcie kwarantanny przeszedłem cały kurs, gdyż zabierałem się za Githuba od roku. Napotkałem jeden znaczący problem wiążący się za pewne z różnicą czasową od zgłoszenia artykułu do jego opublikowania. Przy rozdziale Przeglądanie historii niektórzy mogą napotkać się ze problemem podczas wpisywania > git diff HEAD master main.c gdyż od 1 października Github zmienił nazwę etykiety ostatniego commita master na main w ramach walki z rasizmem. Miałem z tym niemały problem próbując wykonać powyższą komendę, a potem znów zrobić checkout na master oraz ostatecznie pushować wszystko. Google po skopiowaniu sentencji z terminala informującej o błędzie odsyła do starych artykułów na stackoverflow, gdzie była inna geneza błędu i nic to nie pomaga. Dopiero jak się zapytałem kolegi siedzącym w devie oświecił mnie, że to BLM i zmienili etykietę na main. Stąd moja prośba, aby dla przyszłych osób, które chcą zapoznać się z Gitem z tego kursu zamieścić informację o zmianie. Wiem, że istnieją sposoby na przywrócenie starej etykiety, ale można się przyzwyczaić do korzystania z bez rasistowskich komend.
  17. 1 punkt
    Owinołem kabel od dysku na kablu od hub 3.0 i wszystko działa wifi jest chyba nawet lepsze niż wcześniej prędkości lepsze niż na karcie sd o jakieś 140MB/s jeszcze raz dziękuję za pomoc
  18. 1 punkt
    Cześć, systemami wbudowanymi interesuję się od jakiegoś roku. Spodobała mi się zarówno warstwa elektroniczna (projektowanie układów, lutowanie itp.) jak i programistyczna. Jak na razie nie mam zbyt wielkiego doświadczenia, jednak staram się je zdobywać tworząc coraz to nowe projekty. Zawsze szukam nowych źródeł wiedzy i wiem, że tutaj na pewno takie znajdę, dlatego postanowiłem dołączyć do forum.
  19. 1 punkt
  20. 1 punkt
    Witam Jestem Przemek, mam 21 lat, studiuję automatykę i robotykę. Chcę lepiej nauczyć się programować mikrokontrolery. Pozdrawiam.
  21. 1 punkt
    Do tego by pogadać z sąsiadem za pomocą kodu Morse'a nie potrzebujesz żadnych Arduino tak jak nie potrzebowali tego ludzie 100 lat temu. Kod ten jest specjalnie wymyślony do tego, by nadawać i odbierać go mógł człowiek wyposażony w co najmniej jeden palec, uszy i mózg. Potrzebujesz (twój kolega także): jakiś przycisk/wyłącznik, tani bipczak robiący piip gdy dostanie kilka woltów napięcia i bateryjkę. Jeśli jesteś ambitny to zrobisz sobie (lub kupisz) specjalny klucz do nadawania, ale uszy do odbioru musisz mieć własne. No a dalej to 200 metrów kabelka dwużyłowego i kilka tygodni treningu, choć nawet od razu - przy pomocy karteczki z tabelą kodową - możesz zacząć się bawić. Gdzie tu miejsce na Arduino?
  22. 1 punkt
    No to problem się komplikuje, gdyż 500m to już duża odległość i same uniwersalne GPIO nie wystarczą. Potrzebujesz interfejsu, który umożliwi Ci komunikację na taka odległość i to jest pierwszy problem. Programu Ci nie napiszę, a co do schematu to .... potrzebny jest z reguły w każdym urządzeniu NADAJNIK i ODBIORNIK. Wszystko zależy jak rozwiążesz problem 1 - czyli interfejs. To jest moim zdaniem największy problem Twojego projektu Generalnie można sobie wyobrazić takie połączenie: NADAJNIK_1 -> ODBIORNIK_2 ODBIORNIK_1 <- NADAJNIK_2
  23. 1 punkt
    Obecnie student 3 roku AiR, wydział Mechaniczny Politechniki Śląskiej. Mój program należy brać z dystansem,bo rocznik niżej ma już zupełnie inną podstawe programową. 1 rok to głównie matematyka,mechanika i przedmioty które bardziej mi pasują na inżynierie materiałową jak Zasady doboru materiałów inżynierskich. Jeśli chodzi o bardziej kierunkowe przedmioty to praktycznie sucha teoria, chociaż mieliśmy zajęcia gdzie bawiliśmy się robotami fanuca. Do tego obowiązkowe rzeczy do odhaczenia jak filozofia. 2 rok- więcej matmy oraz zamiast mechaniki mamy wytrzymałość materiałów. Do tego C++, SQL,jakieś sieci neuronowe i metody numeryczne. No i pełno rysunku technicznego (w tym PKM, co przy zdalnym nauczaniu i totalnym olaniu nas przez prowadzących skończyło się dla wielu tragicznie). Generalnie od IV semestru całe te studia to jest jeden wielki pic na wode. Zdecydowana większość prowadzących miała nas gdzieś,a zajęcia wyglądały na zasadzie wrzucenia prezentacji i listy zadań do wykonania. Po każdym roku miałem mieć 2 tygodnie praktyki produkcyjnej. Ale dopóki było to względnie związane z kierunkiem, uznawali. Teraz, na V semestrze dopiero zaczynają się ciekawsze dla mnie przedmioty (spawalnictwo, przedmioty związane z maszynami do obróbki) ale jako że plan zmienia się z tygodnia na tydzień,to nie wiem jak one będą wyglądały. W szczególności,że wydział ponownie jest zamknięty i wszystkie zajęcia mam zdalnie. A i tak najlepsze co wyciągłem ze studiów, to certyfikowane szkolenie z programowania PLC Siemensa. No i chciałem wyhaczyć uprawnienia spawalnicze,ale zamknęli mi wydział i nie wiadomo jak to będzie teraz wyglądać.
  24. 1 punkt
    Bardzo ciekawy przypadek i będę śledził ten wątek wszak każdemu może się to przytrafić.Wiedza o przyczynach jest bezcenna.Zapytam jeszcze czy masz zainstalowaną Javę w weresji najnowszej.Być może coś z czymś się gryzie i to cała przyczyna.Nie wiem czy w Arduino jest coś z Pythona jeśli jest to warto zainstalować najnowszą wersję.Krótko mówiąc odinstaluj Arduino zainstaluj Javę,Pythona a następnie Arduino.
  25. 1 punkt
    @Lolheadshootpl witam na forum, przeniosłem Twój temat do właściwego działu Na czym dokładnie utknąłeś? Taka animacja to nic trudnego, więc nie wiem gdzie dokładnie jest problem. Widziałeś np. ten poradnik, w którym omówiłem sposób sterowania tymi diodami? Kurs Arduino, poziom II: https://forbot.pl/blog/kurs-arduino-ii-diody-rgb-tradycyjne-oraz-ws2812-id15495 (treść, która Cie interesuje jest w drugiej połowie poradnika).
  26. 1 punkt
    @Dawidowski wszystko zależy od konkretnego obwodu, ale jeśli jest to coś prostego to najpewniej podczas zwarcia, stosunkowo duży prąd przepływa przez cały układ - mógł więc uszkodzić się również element, który był fizycznie w całkiem innym miejscu. Chodzi Ci o zasilacz czy moduł stabilizatora/przetwornicy?
  27. 1 punkt
    @matrix0606 w przypadku takich bibliotek są 3 łatwe drogi: Sprawdzenie dokumentacji (plik readme itd). Sprawdzenie czy autor nie dołączył przykładów. Znalezienie innych projektów w sieci, w których użyto tej biblioteki. Jeśli żadna z tych metod nie przyniesie skutku to powinna Ci się już zapalić czerwona lampka, bo to trochę podejrzane - ktoś wrzucił bibliotekę, ale nie ma o niej nigdzie słowa? Coś tam musi nie grać Jeśli jednak bardziej Ci zależy to należy przejść do samodzielnej analizy plików z kodem i plików nagłówkowych. Czasami są tam komentarze, które pozwalają domyślić się jak należy wykorzystać bibliotekę. Dobrym początkiem jest chociażby sprawdzenie jakie funkcje są dostępne w ramach tej biblioteki - jej nazwy mogą być dużą podpowiedzią.
  28. 1 punkt
    @MrH4ze przykro mi, ale niestety nie jestem w stanie zrozumieć dokładnie Twoich postów. Dla jasności, nie chodzi o kod - nie rozumiem treści postów... Może ktoś inny będzie w stanie to rozgryźć i zrozumieć o co chodzi. Dla formalności wklejam tylko dwa linki: https://forbot.pl/blog/polityka-przyjaznego-forum-ppf https://forbot.pl/forum/topic/12581-jak-otrzymac-pomoc-od-obcych-ludzi-w-internecie/
  29. 1 punkt
    Te biblioteki, które używasz to są głównie biblioteki "zewnętrzne" - nie obsługują one konkretnego mikrokontrolera (mówimy wtedy o bibliotekach, które nazywamy "core") jak np. funkcja digitalWrite(). Więc to co dostajesz w projekcie zawiera tylko elementy z core, pozostałe musisz zainstalować albo dodać ich kody źródłowe do projektu. Problem można rozwiązać przez a) zainstalowanie tych bibliotek przez PlatformIO: https://docs.platformio.org/en/latest/librarymanager/ Albo b) pobranie ich kodu źródłowego z konkretnego repozytorium i dodanie go do projektu do katalogu lib, wcześniej zapoznając się z instrukcją, którą rozszerzenie dodaje automatycznie: Opcja a) zapewnia najnowszą w danym momencie wersję biblioteki (PlatformIO powinno też ją aktualizować, gdy wyjdzie nowa), ale chcąc uruchomić projekt na innej maszynie będziesz musiał zainstalować wszystko od nowa. Opcja b) ma taką zaletę, że wraz z Twoim kodem, wędruje też kod biblioteki, więc jak będziesz chciał uruchomić projekt na innej maszynie to wszystko co nie dotyczy core będziesz już miał przygotowane. Natomiast wadą jest to, że nie będziesz miał aktualnej wersji biblioteki, gdy taka się pojawi.
  30. 1 punkt
    @matrix0606 Obecnie najwygodniejszym rozwiązaniem jest zainstalowanie wtyczki PlatformIO do VSCode. Tutaj masz artykuł jak zacząć - https://forbot.pl/blog/platformio-alternatywne-srodowisko-dla-arduino-ide-id28167. Korzystam z tego od ponad 2 lat i polecam każdemu. W razie problemów z PlatformIO stwórz post pod tematem z powyższego linka załącz kod ewentualnie drzewo projektu i wyjście z konsoli wtedy będziemy mogli Ci pomóc.
  31. 1 punkt
    Prawdopodobnie kabel generuje fale które zagłuszają WIFI. Możesz spróbować zmienić kabel, albo owinąć go innym kablem USB, podłączonym tylko z jednej strony do RPi, tak aby działał jako dodatkowy ekran. To wbrew pozorom bardzo powszechny problem. https://www.reddit.com/r/xboxone/comments/8f0pi0/external_hard_drive_and_network_problems/ https://www.intel.com.br/content/www/br/pt/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html https://apple.stackexchange.com/questions/233409/external-hard-drive-knocks-out-wifi-internet https://discussions.apple.com/thread/250070091 https://answers.microsoft.com/en-us/xbox/forum/all/cant-connect-to-wifi-when-hard-drive-plugged-in/61baf370-ffcf-478f-9bcf-c8893c3c86be
  32. 1 punkt
    'C:\Users\PRZEMY~1\AppData\Local\Temp\arduino_build_946990\core\core.a'; reason: Permission denied Masz polskie literki w nazwie użytkownika i to dezorientuje Arduino pod Windowsem.
Tablica liderów jest ustawiona na Warszawa/GMT+01:00
×
×
  • Utwórz nowe...