Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 1 punkt
    Witam wszystkich. Po paru latach od mojej rejestracji na tym forum, mam w końcu przyjemność przedstawić Wam mojego pierwszego poważnego robota - linefollower'a. Na początek trochę o nim: Projekt został w całości sfinansowany przez moją szkołę, ma służyć jako pokaz na dni otwarte, ale planujemy także wybrać się z nim na parę konkursów. 2 płytki, główna i ta z czujnikami zostały zaprojektowane i wykonane przeze mnie. Ścieżki rysowałem 2 pisakami PCB: Edding 1mm i 0,3mm. Z racji, iż jest to moja pierwsza tego typu konstrukcja, to odpuściłem sobie projektowanie całości układu - nie czułem się na siłach żeby zrobić taką skomplikowaną jak dla mnie płytkę - zdecydowałem, że skorzystam ze wszelakich możliwych gotowych modułów, a tylna płytka będzie tylko łączyła poszczególne moduły. Zdaję sobie sprawę, że zyskałem przez to dużo wagi, a także straciłem aerodynamikę, ale tak jak mówiłem: nie liczę na pierwsze miejsca, ta konstrukcja miała mnie przede wszystkim nauczyć trochę o linefollower'ach, pokazać mi pułapki, które mogą gdzieś być. I spełniła tą funkcję. Ze względu na swój przepiękny wygląd płytek domowej roboty, linefollowera nazwałem RetroBot Budowa: Robot został złożony z następujących części: 2 * Silnik Pololu HP 10:1 2 * Pololu TB9051FTG - jednokanałowy sterownik silników 28V/2,6A 2 * Mocowania do micro silników Pololu 2 * Koło Solarbotics RW2 - mocowanie zewnętrzne Moduł STM32F103C8T6 ARM Cortex-M3 Moduł zasilający 3,3V / 5V z gniazdem DC Moduł Bluetooth 2.1 XM-15B 3,3V/5V 9 * Czujnik transoptor odbiciowy KTIR0711S Do budowy użyłem też laminatu, markerów PCB, lakieru izolacyjnego PVB 16, wytrawiacza, listewki węglowej 1 x 5mm, Taśmy i 2 złącz IDC 14, goldpinów, wtyków JST, rezystorów i reszty drobnicy takiej jak np. śrubki 2mm. Rezystory do czujników KTIR zostały dobrane eksperymentalnie, na wartości 560ohm do diody i 10K do kolektora. Ślizgacze natomiast zrobiłem z 2 spiłowanych kulek BB. Masa robota z pakietem wynosi 152g, a bez pakietu 140g. Efekt końcowy: Program, który miałby podążać za linią nie jest jeszcze gotowy, ale robota przetestowałem na programie, dzięki któremu działał jako auto RC. Najlepsze wrażenia były, gdy koła już oblepiły się kurzem - robot ślizgał się ze 2 sekundy zanim ruszył, a driftowanie nim po szkolnym korytarzu to bajka Już nie wspomnę o zainteresowaniu wszystkich, którzy go zauważyli - to chyba niecodzienny widok w szkole Dobry efekt tworzył się również wtedy, kiedy jedno koło kręciło się do przodu a drugie do tyłu, robot wyglądał wówczas jak jakiś wirujący krąg światełek Nie mam niestety filmu z tych wyczynów, ponieważ mój telefon służył do sterowania robotem przez BT, jednak postaram się je nagrać w najbliższym czasie. Myślałem też, żeby zrobić drugą wersję przedniej płytki: taką, na której byłby tylko jeden ballcaster i krótsza listewka węglowa, wówczas mógłbym szaleć robotem bez obawy, że zepsuję płytkę z czujnikami Podziękowania: Chciałem również serdecznie podziękować kolegom z tego forum, którzy pomogli mi w budowie tego robota, a więc: @marek1707, za pomoc w temacie https://forbot.pl/forum/topic/12264-podlaczenie-czujnikow-ktir0711s-do-line-followera/, a także starszym: https://forbot.pl/forum/topic/11090-jakie-czujniki-do-linefollowera-pomoc-w-wyborze/?page=1 @Treker, za pomoc w temacie https://forbot.pl/forum/topic/12239-kola-do-line-followera/, a także: https://forbot.pl/forum/topic/12264-podlaczenie-czujnikow-ktir0711s-do-line-followera/ @Nawyk, za pomoc w temacie https://forbot.pl/forum/topic/12264-podlaczenie-czujnikow-ktir0711s-do-line-followera/ Galeria: Czyli to, na co pewnie każdy czekał Pierwsze kilka zdjęć to te z budowy przedniej płytki, potem już niestety nie pamiętałem i zrobiłem zdjęcia tylko ostatecznego wyniku PS: Koniecznie dajcie znać w komentarzach, co myślicie o tej konstrukcji i co można by poprawić w kolejnej wersji
  2. 1 punkt
    Cześć Od pewnego czasu projektuje system do zarządzania smart domem i urządzeniami IoT oraz asystenta głosowego. Założenia mojego projektu to asystent ma być po polsku cała instalacja i konfiguracja ma być banalnie prosta - wszystko możliwe do edycji w intuicyjnym gui poprzez stronę internetową Co już działa? Można dodawać własne intencje po jakich asystent interpretuje naszą wypowiedź i wybrać działanie jakie ma wykonać (obecnie podajemy link na api jakie ma rzucić requesta, czyli na przykład może wyłączyć jakiś przekaźnik, zapalić led na dany kolor itp) Można dodawać własne czujniki, które będą widoczne w gui z możliwością edycji tekstu, ikon i koloru. Parę screenów z wyjaśnieniami: powyżej Widoczne czujniki. Dane odbierają bardzo prosto: czujnik(ten, że tak powiem bardziej fizyczny) musi wysłać na api requesta w stylu ip/sensors/nazwaCzujnika/wartość (nazwa oczywiście wybrana i edytowalna przez nas), zatem przez espEasy da się do ogarnąć Poza tym wartości w danych 'kafelkach' odświeżają się same z siebie (bez przeładowania całej strony oczywiście), także zawsze dane są aktualne. Te nieprzyjemne dla oka nazwy typu textTopRight są po to by było widać które pole z formularza któremu polu odpowiada. Tekst na środku największą czcionką to tytuł. Dodatkowo można prawie w każdym z tych miejsc dodać ikonę (poprzez formularz w jednym ze sceenów niżej) dowolną z https://fontawesome.com/icons?d=gallery podając po prostu jej class, czyli w przypadku https://fontawesome.com/icons/comment?style=solid będzie tam trzeba umieścić: fas fa-comment. powyżej podgląd konfiguracji. Jak widać można ustawić jakie urządzenia mają znaleźć się w zdaniu, jakie intencje, czy ma wychwytywać kolory.. W Pierwszym przykładzie (id1) (teraz tylko zauważyłem - tutaj do poprawnego działania pole Colors powinno być true )wyrażenie by zmienić led na kolor czerwony mogłoby brzmieć: "Zapal led na kolor czerwony" lub "uruchom led na niebiesko". By wyłączyć led należałoby powiedzieć "wyłącz led' Tu widać formularz dodawania Czujnika. Asystent głosowy wyłapuje keyword za pomocą Snowboya, mowę zamienia na tekst i zbiera z niego intencje dzięki wit.ai, a interpreter konkretnych intencji to już system napisany przeze mnie w javie. Chciałbym w przyszłości dodać możliwość tworzenia własnych motywów graficznych gui. Obecnie do dodania obsługa asystenta głosowego bezpośrednio na stronie (obecnie działa on jako osobna aplikacja python3) i sporo innych rzeczy. Na przykład wykresy z grafany. Pytanie ode mnie co sądzicie? Czy ktoś ewentualnie chciałby potestować gdy wydam w miarę stabilną i bardziej funkcjonalną wersję? Docelowo chciałbym by wszystko uruchamiało się z dockera.
  3. 1 punkt
    Jakiś czas temu wspominałem, że ARM udostępnił rdzeń Cortex-M1 dla FPGA oraz planuje niedługo podobnie postąpić z Cortex-M3. Trochę czasu minęło i faktycznie na stronie ARM DesignStart pojawił się link do przykładowej implementacji Cortex-M3 w FPGA: https://developer.arm.com/products/designstart/designstart-fpga Aby pobrać pliki musimy się zarejestrować, ale na szczęście dostęp jest darmowy. Ze strony ARM pobieramy archiwum z przykładowym projektem używającym Xilinx Vivado 2018.2 oraz płytkę Arty-A7 firmy Digilent https://store.digilentinc.com/arty-a7-artix-7-fpga-development-board-for-makers-and-hobbyists/ W załączonych plikach znajdziemy dość dobrą instrukcję "krok po kroku", jak możemy zbudować przykładowy projekt. Jest nieco długa (80 stron), więc przyznam że przeczytałem ją mocno pobieżnie. Sam schemat projektu wygląda następująco: Jak widzimy rdzeń Cortex-M3 jest dostępny jako moduł IP. Możemy więc użyć go w innym projekcie, co więcej nie musimy używać Arty-A7 - możemy go nawet symulować. Procesor możemy również dostosować do naszych potrzeb. Domyślnie posiada on 32kB pamięci programu oraz 32kB pamięci RAM. Można oczywiście dołączyć zewnętrzną pamięć - w przykładzie użyta jest pamięć QSPI Flash, jeśli na płytce mielibyśmy np. DDR moglibyśmy z niej skorzystać. Również pamięć wbudowaną można konfigurować (program do 128kB, dane do 1MB) , chociaż tutaj limitem są zasoby FPGA. Przykładowy projekt to ogromne ułatwienie na początek. Postępując zgodnie z instrukcją, właściwie od razu można przystąpić do syntezy. Jakieś 10 minut później widzimy efekt: Wykorzystaliśmy większość zasobów układu Artix7-35T, ale używając np. wersji 100T mielibyśmy jeszcze sporo miejsca. Układ FPGA konfigurujemy jak każdy inny przykład, po chwili na porcie szeregowym zobaczymy wynik działania przykładowego programu: Jego kod dostarczany wraz z projektem, możemy więc bez problemu zacząć pisanie własnego kodu. Na stronie DesignStart znajdziemy informację o dedykowanej płytce z interfejsem dla debuggera, niestety jeszcze niedostępnej: https://developer.arm.com/products/system-design/development-boards/designstart-daplink-board Na koniec zdjęcie płytki ARTY-A7 z działającym na niej rdzeniem Cortex-M3:
  4. 1 punkt
    Nieśmiało przypominam o istnieniu polecenia "apt-cache" z bardzo fajnym parametrem "search"... Przy okazji: aktualny (przykładowo) Jessie i aktualny Stretch to dwa różne światy... a oprócz nich istnieje jeszcze parę. Może zdradzisz nam tajemnicę, jaką masz wersję systemu? Podaj wynik: lsb_release -a
  5. 1 punkt
    Dobrze. Czy programy które tu wrzucasz jakoś weryfikujesz na sprzęcie? Bo wiesz, możemy gapić się na program przez cały dzień (ja tego nie robię), gadać o jakichś wycudowanych rzeczach a mogą tam siedzieć babole zupełnie podstawowe. Warto więc to kompilować, ładować do Arduino i sprawdzać funkcjonalnie. Masz jakiś model tego sprzętu? Te wszystkie przełączniki, mostki, silniki itd? Bo jeśli nie, to już czas by to zbudować. A teraz o programie. Do tej pory Twój kod "nie widział" czasu. Była jakaś pętla której czas wykonania nie miał znaczenia, obracała się w kółko i tak jak mogła najszybciej (najczęściej?) wykonywała sekwencję czytania tego i owego, sterowała wyjściami itd. Gdy zaczynasz mówić o opóźnieniach czy szybkości zmian pewnych sygnałów (tutaj: wysterowania silników) musisz zacząć zauważać upływający czas. Mikrokontrolery mają wiele mechanizmów to wspomagających - począwszy od sprzętowych timerów, poprzez moduły zegarów RTC na systemie przerwań kończąc. Twój program wygląda na prosty - nawet w swojej ostatecznej formie może nadal wyglądać jak prosta pętla więc na razie spróbujemy zabazować na zwykłym opóźnieniu. To nie jest w ogólności polecany mechanizm, bo zamula procesor i w przypadku dużych opóźnień robionych funkcją delay() zamienia skomplikowane CPU w cegłę. Można tu z pewnością dyskutować jak to zrobić najładniej, bo w Arduino są np. biblioteki do okresowego wołania funkcji czy obsługi timerów bez wnikania w szczegóły sprzętu, ale moim zdaniem nie jesteś jeszcze gotowy na problemy synchronizacji, zmienne współużywane i takie tam. W miarę rozwoju będziesz miał (nomen omen) czas na zgłębianie tych zagadnień. Zatem moja rada: pętla wykonywana (w przybliżeniu) co stały odcinek czasu. Makieta kolejowa to nie apteka i nawet jeśli metoda wprowadzenia stałego opóźnienia nie zapewnia rzeczywście stałej częstotliwości wywoływania funkcji, wydaje się że tu wystarczy. Wstawiasz zatem na końcu pętli loop() wywołanie delay(50). Ponieważ cała reszta rzeczy wykonywanych w pętli jest szybka, dodadzą one niewiele własnego opóźnienia do postulowanych 50ms i z dobrym przybliżeniem możesz uznać, że od tej pory jeden przebieg pętli głównej w Twoim programie wykonuje się 20 razy na sekundę. Wstaw to i sprawdź, czy widzisz istotną różnicę w działaniu swojego dotychczasowego programu. A teraz druga ważna rzecz: skoro silniki mają być sterowane "miękko", z powolnym narastaniem czy opadaniem prędkości musisz zerwać ich bezpośrednie połączenie z potencjometrami. Powinieneś wprowadzić do programu kolejny poziom przetwarzania sygnałów, bo do tej pory miałeś tylko jeden: odczyt z potencjometru był zarazem prędkością silnika. 1. Na pierwszym poziomie będziesz teraz wczytywać sygnał z potencjometru - od tej pory jest to wartość.. hm, tylko pożądana (docelowa). Musisz ją pamiętać np. w zmiennej pot_target_speed z odpowiednim numerkiem kanału. Acha, przy okazji: staraj się nie wiązać wielkości przetwarzanych w programie z ich sprzętowymi cachami. Wczytujesz wysterowanie z potencjometru i akurat w przypadku tego procesora masz 10-bitowy ADC więc dostajesz liczby 0..1023. Nie powinieneś jednak tego przekazywać dalej, bo za chwilę cały program będzie posługiwał się takim dziwnym zakresem, któyry wynika tylko i wyłącznie z cechy tego konkretnego ADC. Spróbuj mapować już w funkcji odczytującej potencjometr wartość wyjściową tak, by była w zakresie np. 0..100. W lokomotywie nie potrzebujesz większej precyzji niż 1% więc strata dokładności nie zaboli, a od tej pory masz fajny zakres liczb. Zauważ też, ze za chwilę będziesz odbierał dane z pilota a tam w ogóle nie ma odniesienia do ADC, jego 10-bitowości i zakresu 1024 wartości. Ukrywając więc potencjometr i ADC przed resztą kodu dość wcześnie uwalniasz się od sprzętu i masz komfort pracy z arbitralnie dobranym zakresem, tutaj: prędkości. 2. Na kolejnym poziomie będziesz miał prędkość aktualną silnika czyli to możesz pokazywać na wyświetlaczu w lokomotywie Musisz zatem dopisać funkcję (np. get_motor_speed()) , która będzie otrzymywać prędkość "docelową" a oddawać prędkość "aktualną" - także w zakresie 0..100, która podąża w kierunku tej docelowej z pewną, ograniczoną szybkością zmian. Poradzisz sobie? Pomyśl jak chcesz wykonać to "dopędzanie" prędkości zadanej, bo od tego będzie zależała ch-ka przyspieszenia lokomotywy. Dwa najczęstsze przypadki to nadążanie ze stałą prędkością zmian (czyli za każdym razem dodajesz/odejmujesz tyle samo do/od prędkości aktualnej - tak przyspiesza masa ciągnięta stałą siłą) lub nadążanie z prędkością zależną do różnicy obu prędkości (czyli dodajesz/odejmujesz tym więcej im jesteś dalej od docelowej - tak ładuje się kondensator lub stygnie piekarnik). Na razie mamy tylko prędkość dodatnią, ale w połączeniu ze zmianami kierunku przełączników zacznie być ciekawie, prawda? Acha, no i oczywiście funkcja ustawiająca fizyczny PWM będzie teraz dostawać prędkość aktualną 0..100 więc powinna już we własnym zakresie mapować (znów ukrywamy sprzęt/timer jak najgłębiej) tę wielkość na wysterowanie 0.255 wyjścia PWM.
  6. 1 punkt
    No właśnie z tym może być problem bo ciągle nie mam trasy i myślę z czego ją można by zrobić
  7. 1 punkt
    No jasne, ale ze mnie d. wołowa, przecież pisałeś o makietach. Ale te silniki to chyba nie w lokomotywach, prawda? Albo na osobnych, izolowanych od siebie torach. To bardziej jakieś karuzele na makiecie czy coś? Bo jeśli w ruchu to może powinieneś pójść w DCC? Acha, czyli 3 potencjometry. Jakoś zrozumiałem, że jeden wspólny. No dobra, to trzy piny analogowe, trzy gałki, jedna funkcja oddająca wartość wskazanego potencjometru i trzy zmienne globalne przechowujące odczyty. Do roboty. BTW: Czy wymyśliłeś już sposób sterowania tymi silnikami przez podczerwień? Jaki to pilot? Masz już upatrzony? Bo trzeba a) znać protokół przesyłania kodów - a jest kilka różnych, b) obmyślić sposób wybierania silnika i regulacji jego prędkości. Może to być np. wciśnięcie jednego z 10 przycisków cyfrowych - wtedy masz tylko(?) 10 różnych prędkości ale za to szybkie reakcje, mogą to być przyciski "w górę/w dół" po troszeczku zmieniające prędkość (plus ew. jakiś awaryjny STOP) itp. Jeśli masz to jakoś przemyślane, napisz, bo to wszystko już za niedługo będzie musiał odbierać, interpretować i wykonywać Twój program.
  8. 1 punkt
    Zawsze robię kopię rsyncem w locie (fakt, maszyna na którą robię kopię to linux) i nigdy nie miałem problemu z nagraniem nowej karty i uruchomieniem pod raspbianem. Słowa kluczowe: --one-file-system, --numeric-ids.
  9. 1 punkt
    Witam Jestem Bartek, dopiero zaczynam zabawę z elektroniką - jestem w tym kompletnie zielony. Moją mocna stroną raczej jest mechanika którą właśnie kończę studiować. Dołączyłem do forum ponieważ szukam pomocy przy stworzeniu większego pojazdu balansujacego. Pozdrawiam wszystkich
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...