mactro

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.

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.

Serio? Czyli fakt, że nie ma zwierząt na kołach oznacza, że napęd kołowy jest nieefektywny?

Dodałem filmik prezentujący działanie robota.

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...

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

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

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?

Rolling average to po naszemu średnia krocząca

Ale opisy aukcji to Ty czytaj... Co do sterowników na większe prąd zobacz http://roboteq.com/index.php

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.

Gratuluję pierwszej konstrukcji! Czepię się tylko, że skoro jest programowany, to z definicji nie jest robotem BEAM

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

Metalowe są też tu: http://www.trobot.pl/kategoria-produktu/makeblock/kola-i-pasy-zebate/

Jaką masz ustawioną prędkość transmisji? Czy w jakikolwiek sposób sprawdzasz poprawność przesłanych danych (sumy kontrolne)?