Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją od 16.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
    @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ń.
  12. 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..
  13. 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
  14. 1 punkt
  15. 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).
  16. 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(),.
  17. 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.
  18. 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ć...
  19. 1 punkt
    LM358/324 zadziała do -300mV przy zasilaniu tylko napięciem dodatnim. Inna opcja wygenerować napięcie ujemne np ILC7660.
  20. 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 :)
  21. 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.
  22. 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?
  23. 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ć ;)
  24. 1 punkt
    Napisałem reklamacje, bez problemu mi ją przyjęto i sklep wysłał mi nowe serwo, teraz wszystko śmiga jak powinno.
  25. 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
  26. 1 punkt
    Dodałem do akceleratora sprites znane z komputerów takich jak Amiga, C-64 czy Atari. W tych komputerach dostępne było kilka "duszków". Tego nawet w FT8xx nie ma (chyba, że jednobarwne). Teraz duszki nawet na UNO działają: Widać dwa duszki "duszki". Jeden nie ma oczu, widać jak przenikają przez siebie a pod nimi tło i sześcian. Z punktu widzenia programu dla Arduino duszek, to prostokątny obiekt, w którym kolor 0, jaki by nie był, jest przeźroczysty. Taki duszek jest wysyłany jak bitmapa, więc po podaniu rozmiaru i współrzędnych okna wysyłany jest blok danych a nie piksel po pikselu co pozwala przyspieszyć transfer 4-krotnie w stosunku do adresowania piksel po pikselu. Nie ma ograniczenia co do ilości i rozmiarów duszków. Liczba kolorów 255 + przeźroczyste tło. PS Im dłużej robię akcelerator tym więcej ograniczeń Arduino na AVR widzę. Rzeczy banalne dla ARM dla AVR sa trudne do zrobienia albo niemożliwe. Zmuszany jestem sięgać do rozwiązań z lat 80! Ówczesne mikroprocesory osiągały typowo ok 1MIPS (max ok 3 - pomijam tu 16/32-bit MC680x0 i inne nie 8-bit) więc "dopalacze" były niezbędne ale AVR ma 20 MIPS (tak się chwali producent) przy 20MHz, w praktyce jakieś 15 i nadal wymaga dopalaczy W przypadku Xmega jest lepiej ale cena nie zachęca, ARM będzie lepszy i przeważnie tańszy.
  27. 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; ?
  28. 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
  29. 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"
  30. 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
  31. 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ę.
  32. 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.
  33. 1 punkt
  34. 1 punkt
    Cześć, Póki co mogę się podzielić zadaniami domowymi 6.1 oraz 6.2. Nieśmiało poeksperymentowałem z millis(). /* * Kurs Arduino poziom II * Wyświetlacze 7-segmentowe * Zadania domowe 6.1 oraz 6.2 */ #define SEG_C 2 //Definicje pinów segmentów wyświetlaczy #define SEG_E 3 #define SEG_D 4 #define SEG_G 5 #define SEG_A 6 #define SEG_F 7 #define SEG_B 8 #define Minus 9 //Definicje pinów przycisków #define Plus 10 #define Reset 11 #define mryganie 500 //Okres mrygania kodu błędu int i = 0; //Zmienna "i" służy do określenia wyświetlanej cyfry w pętli głównej int j = 0; //Zmienna "j" służy do resetowania czasu po upłynięciu okresu jednego mrygnięcia unsigned long poprzedniCzas = 0; //Zmienna "poprzedniCzas" zapisuje aktualny czas z komendy millis() przed mrygnięciem kodu błędu void setup() { pinMode(SEG_A, OUTPUT); //Deklaracja pinów wyświetlacza jako wyjścia pinMode(SEG_B, OUTPUT); pinMode(SEG_C, OUTPUT); pinMode(SEG_D, OUTPUT); pinMode(SEG_E, OUTPUT); pinMode(SEG_F, OUTPUT); pinMode(SEG_G, OUTPUT); pinMode(Minus, INPUT_PULLUP); //Deklaracja pinów przycisków jako podciągnięte wejścia pinMode(Plus, INPUT_PULLUP); pinMode(Reset, INPUT_PULLUP); } void loop() { if(digitalRead(Plus) == LOW){ //Jeżeli przycisk "Plus" wciśnięty (zwarty z masą) to zwiększ "i" o jeden i odczekaj aby wyeliminować efekt wielokrotnego wciśnięcia przycisku i++; delay(200); } else if(digitalRead(Minus) == LOW){ //Po wciśnięciu minusa zmniejsz "i" o jeden i--; delay(200); } else if(digitalRead(Reset) == LOW){ //Przycisk "Reset" nadaje zmiennej "i" wartość 0 i = 0; delay(200); } if(i > 9){ //Dwie instrukcje warunkowe ograniczające i do zakresy od -1 do 10 i = 10; } if(i < -1){ i = -1; } wyswietlacz(i); //Wyświetlenie cyfry } void wyswietlacz(int cyfra){ //Funkcja zamieniająca wartość "i" na wyświetlenie konkretnych diod. Cyfra jest zmienną wewnątrz tej funkcje przyjmującą wartość "i" if((cyfra > 9 || cyfra < 0) && j == 0){ //Jeżeli cyfra nie mieści się w zakresie wyświetlania wyświatlacza i zmienna "j" wskazuje początek nowego/pierwszego mrygnięcia to zapisz aktualny czas do zmiennej poprzedniCzas = millis(); } if(poprzedniCzas < millis() - mryganie){ //Jeżeli okres mrygnięcia minął to zresetuj zmienną "j" co spowoduje rozpoczęcie kolejnego mrygnięcia j = 0; } if(cyfra > 9 || cyfra < 0){ //Kolejne sprawdzenie czy zakres cyfry poza zakresem wyświetlacza i... if(poprzedniCzas > millis() - (mryganie/2)){ //jeżeli tak to włącz diody sygnalizujące kod błędu o ile nie mineło więcej niż pół okresu mrygnięcia, zwiększ zmienną "j" tak aby nie nadpisywał się czas w zmiennej "poprzedniCzas" j++; digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, LOW); digitalWrite(SEG_C, LOW); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, LOW); digitalWrite(SEG_G, HIGH); } else{ //Jeżeli natomiast minęło pół okresu mrygnięcia to wyłącz diody digitalWrite(SEG_A, LOW); digitalWrite(SEG_B, LOW); digitalWrite(SEG_C, LOW); digitalWrite(SEG_D, LOW); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, LOW); digitalWrite(SEG_G, LOW); } } else{ //Jeżeli cyfra mieści się w zakresie wyświetlacza to przygotuj zmienną "j" na początek okresu mrygnięcia kodu błędu na wypadek gdyby cyfra przestała się mieścić w następnym obiegu j = 0; } switch(cyfra){ //Instrukcja zamiany konkretnej cyfry na włączenie konkretnych diod tak aby całość była wyświetlana jako ta cyfra case 0: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, HIGH); digitalWrite(SEG_F, HIGH); digitalWrite(SEG_G, LOW); break; case 1: digitalWrite(SEG_A, LOW); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, LOW); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, LOW); digitalWrite(SEG_G, LOW); break; case 2: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, LOW); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, HIGH); digitalWrite(SEG_F, LOW); digitalWrite(SEG_G, HIGH); break; case 3: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, LOW); digitalWrite(SEG_G, HIGH); break; case 4: digitalWrite(SEG_A, LOW); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, LOW); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, HIGH); digitalWrite(SEG_G, HIGH); break; case 5: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, LOW); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, HIGH); digitalWrite(SEG_G, HIGH); break; case 6: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, LOW); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, HIGH); digitalWrite(SEG_F, HIGH); digitalWrite(SEG_G, HIGH); break; case 7: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, LOW); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, LOW); digitalWrite(SEG_G, LOW); break; case 8: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, HIGH); digitalWrite(SEG_F, HIGH); digitalWrite(SEG_G, HIGH); break; case 9: digitalWrite(SEG_A, HIGH); digitalWrite(SEG_B, HIGH); digitalWrite(SEG_C, HIGH); digitalWrite(SEG_D, HIGH); digitalWrite(SEG_E, LOW); digitalWrite(SEG_F, HIGH); digitalWrite(SEG_G, HIGH); break; } }
  35. 1 punkt
    Podręczny, hydrauliczny przecinak do nakrętek...
  36. 1 punkt
    Stąd (cytując opis na Botlandzie):
  37. 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.
  38. 1 punkt
  39. 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).
  40. 1 punkt
    Możesz jeszcze spróbować zmniejszyć w programie prędkość I2C.
  41. 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/
  42. 1 punkt
    analogRead tak w kwestii formalnej.
  43. 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
  44. 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.
  45. 1 punkt
    Oj, po takim potraktowaniu autor wątku chyba już się nie pojawi:(
  46. 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); } } }
  47. 1 punkt
    Jak już ten starty temat został przywołany to warto chyba dodać w tej chwili do tej listy JLCPCB i PCBWay
  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...