Skocz do zawartości

mactro

Użytkownicy
  • Zawartość

    789
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    27

Wszystko napisane przez mactro

  1. O rety... Czy ktoś z przedmówców w ogóle poszukał gdzie są te stałe wykorzystane? void processInput (){ // funkcja przetwarzajaca komeny odbierane przez serial static long receivedNumber = 0; static boolean negative = false; byte c = Serial1.read (); switch (c){ case endOfNumberDelimiter: // odebrano '>' - koniec parasowania liczby, ustawiamy PWM na tą liczbę (receivedNumber) if (negative) SetPWM(- receivedNumber, pwmChannel); else SetPWM(receivedNumber, pwmChannel); // fall through to start a new number - nie było instrukcji break; więc poniższy case też sie wykona dla '>' case startOfNumberDelimiter: // odebrano '<' rozpocznij parsowanie liczby receivedNumber = 0; negative = false; pwmChannel = 0; break; case '0' ... '9': // przetwarzanie nadchodzących cyfr receivedNumber *= 10; receivedNumber += c - '0'; break; case '-': // i dla liczb ujemnych negative = true; break; Zamysłem autora było ustawianie PWM z pomocą komend w stylu x<123>, y<-45>. gdzie x i y zmieniają sterowany silnik. Czy można to zrobić prościej? Pewnie tak i zachęcam autora aby sam spróbował dostosować protokól komunikacji do swoich potrzeb.
  2. Będąc na studiach też miałem o wielu przedmiotach opinię w stylu "a komu to potrzebne?". Duża zapewne w tym wina prowadzących zajęcia, którzy rzadko kiedy zdobywali się na jakieś przykłady rzeczywistych zastosowań. Z biegiem lat jednak widzę, że im bardziej złożony i ciekawy projekt tym więcej "akademickiej" wiedzy wymaga. Zresztą, to wszystko bardzo ogólne rozważania - zupełnie inaczej będzie wyglądać pożądany zestaw automatyka/technika utrzymania ruchu, a zupełnie inaczej osoby odpowiedzialnej za np. system kontroli lotu w rakiecie.
  3. Serio? Czyli fakt, że nie ma zwierząt na kołach oznacza, że napęd kołowy jest nieefektywny?
  4. O! Taki ciekawy projekt, a przeoczyłem go wcześniej... Kilka pytań: - impulsy z nadajników wysyłasz naprzemiennie? - z jaką częstotliwością jest odświeżana pozycja? - nie masz problemów z odróżnieniem odbić fali od właściwego impulsu? - jaki maksymalny zasięg uzyskałeś? - jaka jest dokładność systemu? Na filmiku widać, że współrzędne się zmieniają, ale ile ma to wspólnego z prawdą nie wiadomo...
  5. Hmm, o ile dobrze pamiętam jedną z pierwszych rozmów na temat projektu, niedoskonałość robota miała go w pewien sposób "uczłowieczyć" - zamiast maszynowej precyzji i powtarzalności, ludzkie błędy... Może też chodzić o to aby jego działanie było nieprzewidywalne dla zwiedzających, a może o jeszcze coś innego
  6. Cześć! Chciałbym Wam przedstawić robota „Foto robotoid”, którego wykonałem na zamówienie artysty, Przemysława Jasielskiego . Robot ten powstał na wystawę „Aparat. Retrogresja poprzez postęp technologiczny”, w Sculpture Center Cleveland. Autor o wystawie: Artyści Przemysław Jasielski i Rainer Prohaska prezentują niecodzienne podejście do sztuki i technologii. W ich ujęciu krytyczna idea dlaczego i jak używać najnowszych technologii w sztuce jest zdecydowanie ważniejsza niż czysta fascynacja nowymi gadżetami technicznymi. Pytanie dlaczego powinniśmy dany projekt zrealizować jest o wiele ważniejsze niż to, jakimi środkami osiągamy cel. Rezultatem tej strategii są zawsze fizyczne obiekty dostępne dla widza w realnym świecie, tworzone w opozycji do finalności, produktywności i wydajności. Zawsze zawierają one sporą dawkę poczucia humoru. Jest to ciągłe eksperymentowanie i zabawa definicją obiektu rzeźbiarskiego w kontekście nauki i technologii. Założenia Robot ma mieć możliwość wykrywania zwiedzających galerię i robienia im zdjęć aparatem Nikon D200. Migawka aparatu ma być wyzwalana poprzez fizyczne naciśnięcie spustu. Ruch aparatu ma być możliwy w dwóch osiach Wykonywane zdjęcia mają być drukowane Robot ma mieć możliwie „surowy” wygląd – elektronika i przewody na wierzchu Zdjęcia nie mają być idealne - wręcz przeciwnie, wymagana jest pewna ich losowość i niedoskonałość (tylko pół twarzy w kadrze, zdjęcie rozmyte, nieostre itp.) Konstrukcja mechaniczna Konstrukcja nie mogła być zbyt kompaktowa, tak aby robot z daleka przyciągał wzrok. Dlatego też pionowa oś obrotu nie pokrywa się ze środkiem ciężkości najcięższego elementu urządzenia - aparatu. Wymusiło to konieczność starannego ułożyskowania osi obrotu. Oprócz tego, serwomechanizmy napędzają osi poprzez dodatkowe, zewnętrzne przekładnie zębate. Rozwiązanie to ma na celu zmniejszenie obciążeń działających na elementy serwomechanizmów, uzyskanie dodatkowego momentu i zmniejszenie prędkości obrotowej. Dodatkowo, fajnie wygląda Konsekwencją zastosowania dodatkowych przekładni była konieczność przerobienia serwomechanizmów, tak aby posiadały odpowiedni zakres ruchu. Oznaczało to usunięcie mechanicznej blokady i połączenie potencjometrów mierzących pozycję bezpośrednio z osiami obrotu. Był to najtrudniejszy element całej konstrukcji. Początkowo, chciałem pokrętła potencjometrów przykleić do osi przy użyciu kleju na gorąco, albo kleju do metalu. Niestety, nawet minimalna niewspółosiowość łączonych elementów powodowała, że takie połączenie szybko ulegało uszkodzeniu. Ostatecznie, zastosowałem coś w rodzaju sprzęgła - kawałek gumy wyciętej z dętki rowerowej, wklejony pomiędzy potencjometr i oś - działa bez zarzutu Elektronika Do wykrywania osób znajdujących się w pomieszczeniu zastosowałem czujnik Kinect v2. Docelowe pomieszczenie miało być pozbawione okien, więc nie było problemów niekorzystnym wpływem oświetlenia słonecznego. Do sterowania serwomechanizmami wykorzystuję płytkę DFrobot Romeo. Jest oparta na Arduino Leonardo, jednak posiada dodatkowe złącza, które znacznie ułatwiają podłączenie czujników czy serwomechanizmów. Ważną zaletą jest też możliwość dołączenia osobnego źródła zasilania dla serw. Do wyzwalania migawki użyłem dodatkowego wężyka spustowego, którego przycisk jest wciskany orczykiem serwomechanizmu. Rozwiązanie to było podyktowane głównie łatwiejszym montażem, w porównaniu do wciskania spustu bezpośrednio na aparacie. Oprogramowanie Główny program robota wykonuje się na laptopie, do którego podłączony jest Kinect, Romeo, drukarka i aparat. Program jest napisany w jeżyku C# i pozwala na konfigurację parametrów pracy robota, takich jak zakres ruchu serwomechanizmów, minimalne i maksymalne odstępy pomiędzy robieniem kolejnych zdjęć, prawdopodobieństwo sfotografowania określonych części ciała. W programie wyświetlane jest także ostatnio zrobione zdjęcie. Do odczytywania danych z Kinecta wykorzystuję oficjalne SDK, które jest rewelacyjne - byłem zaskoczony z jaką łatwością mogę pobierać potrzebne dane. Pozwala ono na odczytywanie współrzędnych 24 części ciała, z których program losuje sobie jedną, która będzie śledzona do momentu wykonania kolejnego zdjęcia. Na podstawie otrzymanych współrzędnych obliczane jest wymagane położenie serwomechanizmów, które jest następnie przesyłane do płytki Romeo. W następnej iteracji spróbowałbym odczytywać aktualne położenie serw z potencjometrów. Pozwoliłoby to na stabilniejsze działanie regulatora, który teraz tylko szacuje aktualne położenie na podstawie czasu jaki upłynął od zadania zmiany położenia. Najbardziej skomplikowane okazało się pobieranie zrobionych zdjęć z pamięci aparatu. Niestety nie jest możliwe robienie zdjęć, kiedy aparat pracuje w trybie pamięci masowej i jest widoczny jako zwykły dysk wymienny. Funkcjonalność taką umożliwia tryb PTP (Picture Transfer Protocol), który umożliwia zdalne kontrolowanie aparatu. Niestety, utrudnia to dostęp do pamięci aparatu z poziomu programu. SDK udostępniane przez Nikona zawiera przykłady, które nie działały dla wykorzystywanego modelu. Ostatecznie, wykorzystałem aplikację Smart Shooter 3, która zapisuje zrobione zdjęcia na dysku komputera, skąd już łatwo mogę je odczytać. Podsumowanie Robot został entuzjastycznie przyjęty zarówno przez jego pomysłodawcę jak i przez publiczność obecną na wystawie. Dla mnie był okazją aby w końcu zapoznać się z czujnikiem Kinect, którego łatwość obsługi i funkcjonalność zrobiła na mnie duże wrażenie. Mam nadzieję, że powyższy opis będzie dla kogoś pouczający i być może stanie się inspiracją przy kolejnych projektach Pomysłodawca robota, Przemysław Jasielski
  7. Dlaczego zdecydowałeś się na taki układ napędu? Odometria przy poślizgu kól jaki tu masz już na wstępie jest utrudniona. Czy przy tworzeniu mapy korzystasz z jakiś metod dopasowywania skanów?
  8. Ale opisy aukcji to Ty czytaj... Co do sterowników na większe prąd zobacz http://roboteq.com/index.php
  9. rmdiy, Twoja metoda ma jeden mankament: popsuje się nam numeracja komponentów na płytkach. Przykładowo, jeśli rezystory na płytce miały oznaczenia od R1 do R10, to na drugiej wklejonej grupie będą R11 - R20, na trzeciej R21-R30 itd. Opisany skrypt tworzy nową warstwę opisu (_tnames i _bnames), w której na każdej płytce oznaczenia elementów są takie same. Ważne jest, aby przy generowaniu plików gerber do produkcji, czy pdf do wydruku opisy generować właśnie z tej warstwy, a nie domyślnych tnames, bnames.
  10. Gratuluję pierwszej konstrukcji! Czepię się tylko, że skoro jest programowany, to z definicji nie jest robotem BEAM
  11. Dwukierunkowy konwerter poziomów logicznych Użyteczny np. w komunikacji I2C pomiędzy urządzeniami o różnych napięciach zasilania. Testowałem też przy komunikacji przez UART z prędkościami do 115200bps. Jak to działa? 1. Jeżeli żadna ze stron nie ściąga swojej linii do masy, po obu stronach mamy stany wysokie zapewniane przez rezystory podciągające do odpowiedniego napięcia zasilania. 2. Jeśli linia DATA_3V3 jest ściągnięta do masy, napięcie Vgs przekracza próg załączenia i tranzystor T1 zaczyna przewodzić, dzięki czemu DATA_5V również zostaje ściągnięte do masy. 3. Najciekawszy jest przypadek kiedy linia DATA_5V będzie miała stan niski. Wtedy do gry wchodzi dioda pasożytnicza tranzystora będąca pomiędzy drenem, a źródłem. Poprzez nią napięcie na linii DATA_3V3 zaczyna spadać, aż dochodzi do momentu kiedy napięcie Vgs przekracza próg załączenia tranzystora i zaczyna on przewodzić. Obie linie mają wtedy stan niski. Uwagi: Układ może służyć jako konwerter pomiędzy innymi poziomami zasilania, jednak należy pamiętać, że napięcie po stronie źródła tranzystora T1 nie może być wyższe niż po stronie drenu. Nie powinno być też niższe niż 2,5V (maksymalne napięcie Vgs, przy którym tranzystor 2N7002 zaczyna przewodzić) logic_converter.sch
  12. Metalowe są też tu: http://www.trobot.pl/kategoria-produktu/makeblock/kola-i-pasy-zebate/
  13. Jaką masz ustawioną prędkość transmisji? Czy w jakikolwiek sposób sprawdzasz poprawność przesłanych danych (sumy kontrolne)?
  14. O, miło widzieć, że ktoś wykorzystał nasze podwozie do tak szlachetnego celu jak serwowanie wódki Robota mobilnego też programowałeś, czy jeździ na zdalnym sterowaniu? Ogólnie gratuluję udanej i bardzo estetycznej konstrukcji
  15. Prawdziwy problem leży gdzie indziej. W tych podwoziach enkodery mocowane są na osi koła. Nie znalazłem w opisie jaką mają rozdzielczość, ale raczej nie będzie to więcej niż jakieś 60 impulsów na obrót koła. Przy średnicy kół ok. 50 mm, da Ci to rozdzielczość ok. 2-3mm przebytej drogi na impuls. Na pierwszy rzut oka może to się wydawać nie najgorszą wartością, ale tak naprawdę, zastosowanie praktyczne takich enkoderów jest prawie żadne. O regulatorze prędkości możesz właściwie zapomnieć, podobnie o wykonywaniu skrętów, które będą miały dokładnie 90 stopni. Tak naprawdę potrzebujesz albo enkoderów inkrementalych na wale silnika, (np. jak tu http://www.trobot.pl/sklep/z-przek-adni/silnik_25dx52l_341_hp__z_enkoderem/) albo enkoderów absolutnych na kole, ale z rozdzielczością przynajmniej 10 bitów. Do tego drugiego rozwiązania możesz szukać produktów firmy Austriamicrosystems.
  16. Mam nadzieję że będzie się rozwijał. To jest poważna próba wprowadzenia robotyki jako stałego elementu zajęć technicznych czy informatyki w gimnazjach. Dzięki temu dzieciaki które w innych okolicznościach nie miałyby szansy na kontakt z robotyką mogły tego spróbować. Jasne że nie wszystko było idealnie, nie na wszystko też mieliśmy wpływ. To że nauczyciele dali sobie radę i dzielili się doświadczeniami to tylko dobrze - to też ważny aspekt projektu. Po tych niemal już dwuletnich doświadczeniach, wiemy jak to zrobić jeszcze lepiej Na zakończenie: zmontowany przez nas filmik pt. "Co robot robi w szkole?": i kanał Facebook jednej ze szkół: https://www.facebook.com/pages/Gimnazjum-im-Jana-Paw%C5%82a-II-w-%C5%81%C4%99czycy/294315763303
  17. Pamiętaj też, że każdy dodatkowy stopień przekładni zmniejsza jej sprawność, więc moc, którą otrzymasz an wale, może być znacznie mniejsza niż moc samego silnika.
  18. Fajny robot Najbardziej ciekawi mnie wykrywanie piłki: czy na podstawie obrazu z jednej kamery jesteś w stanie określić położenie piłki na całym korcie? Albo przynajmniej połowie? Jak Twój algorytm radzi sobie z różnymi nawierzchniami, zmiennym oświetleniem itp.? Planujesz dalej rozwijać swoją konstrukcję, czy odkładasz projekt na półkę?
  19. Tzn samo porównywanie skanów żeby ustalić przemiszczenie w literaturze występuje jako scan matching. A Simultaneous Localization And Mapping (SLAM) mamy jak dołożymy jeszcze budowanie mapy.
  20. Po kolei: na filmiku moim zdaniem kluczowe jest właśnie to ramię, którego nie chcesz. Skoro skaner jest do niego przymocowany, to wystarczy odczytywać położenia wszystkich przegubów ramienia i z tego łatwo można wyliczyć dokładne położenie i orientację końcówki. Zupełnie inaczej ma się sprawa ze skanerem trzymanym w ręku. Bobby obawiam się, że trochę się rozpędził. Wskazania położenia na podstawie danych z akcelerometru rozjadą Ci się z rzeczywistością po kilku - kilkunastu sekundach. Wszystko przez to, że całkując pomiary, całkujesz też i błąd pomiarowy. Z ratunkiem przychodzi tu sam skaner i metody SLAM. Ogólnie chodzi o to, że przykładowo, w pierwszym skanie z chmury punktów udało Ci się wyodrębnić coś co przypomina narożnik pokoju. Na następnym skanie ten narożnik też jest, ale nieco przesunięty. Można stąd wnioskować, że sam skaner zmienił swoje położenie. Jeśli połączy się to z danymi z innych czujników, można rzeczywiście otrzymać całkiem fajne rezultaty, choć na precyzję taką jak na filmiku raczej bym nie liczył.
  21. matty, akurat 'liczba' ma sens i nie będzie rosła bardziej niż do 5 (gdyby wszystkie czujniki widziały linię). Jest w końcu zerowana zaraz po wywołaniu funkcji read. Zmienna 'offset' noże tu służyć jedynie do skorygowania jakiś mechanicznych niedoskonałości robota (np. silniki nierównej mocy), na skutek których, przy podaniu równego wypełnienia PWM na silniki, robot zamiast prosto skręcałby. Wtedy korygując wartość offset powinieneś móc doprowadzić do tego, że będzie jeździł prosto. Na razie ustaw ją jednak na 0.
  22. Dwie rzeczy, które się jako pierwsze rzucają w oczy: - co ma robić offset i czemu jest równy 2? - regulator PID powinien być wywoływany w stałych odstępach czasu, np co 10ms. U Ciebie jest po prostu wrzucony w pętlę, co w żaden sposób nie gwarantuje stałej częstotliwości wykonywania.
  23. Czy liczyliście w jakikolwiek sposób ten chwytak, tzn. siłę potrzebną do utrzymania butelki z piwem? Będzie wykonany z gołego aluminium, czy może będą jakieś gumowe okładziny?
×
×
  • Utwórz nowe...