Ramię robotyczne własnej konstrukcji

Witam,

chciałbym tutaj zaprezentować początek projektu (choć i tak już nieco zaawansowany) budowy własnego ramienia robotycznego. Projekt składa się z kilku faz. Często równoległe wykonuję różne zadania związane z tym projektem. Ale od początku.

Faza 1.
Polegała ona na określeniu jaki typ ramienia robotycznego chcę zbudować, jak rozwiążę zabudowę napędów, jaki typ napędów, czym sterowane i wiele innych pytań na które musiałem sobie odpowiedzieć po drodze.
Po namyśle i zgrubnych analizach obciążeń wybrałem typ budowy ramienia robotycznego pokazany na zdjęciach poniżej:

oraz

Elementy wykonałem rysując na własnym oprogramowaniu CNCPaint na własnej frezarce (art "Frezarka numeryczna z własnym sterowaniem"). Elementy ramion są wycięte ze sklejki, elementy napędowe to standardowe koła zębate aluminiowe i paski do nich ze specjalnego tworzywa.
Ten typ budowy nie obciąża tak ramion mojego robota, ponieważ wszystkie serwa są skupione w zasadzie w jednym miejscu. Test obrotu takiego ramienia wyszedł pozytywnie, choć muszę przyznać, że nie były zamontowane wszystkie serwa, a ma ich być ogółem pięć. Rysunek drugi przedstawia właśnie obrotnicę.

Faza 2
To jak dotychczas najbardziej skomplikowana część projektu. Polega ona na zbudowaniu układu sterowania ramieniem. Rozważałem zastosowanie standardowego PC-ta wraz z jakąś kartą IO, ale ostatecznie zdecydowałem się na nietypową architekturę. Główną jednostką jest Raspberry Pi ver.3, na którym działa mój program napisany w Lazarusie (Object Pascal). Jego zadaniem jest nadzór nad wszystkimi elementami sterowania powstającego robota, interakcja z operatorem, możliwość budowania skryptów przemieszczenia ramienia, wykonywania pojedynczego ruchu jedną osią, nadzór nad prawidłową pracą, rejestracja ewentualnych błędów, takich jak przekroczenie zadanego zakresu dla danego silnika, błąd przemieszczenia. Elementami nadzorującymi przemieszczenie, czyli zmianę kąta nachylenia danej osi są mikrokontrolery ATMega8. Każdy enkoder danego silnika jest podłączony do odpowiedniej atmegi8. Po stronie mikrokontrolerów rezyduje program (napisany w Bascomie), którego zadaniem jest zliczanie impulsów enkodera, generowanie sygnałów krok/kierunek odczyt danych z i wysyłanie do RPi. Raspberry Pi jest spięte z atmegami interfejsem I2C. Generalnie na każdej z atmeg jest ten sam program, różnią się tylko adresami (protokół I2C). Nastawy jakie otrzymują te atmegi z RPi są już jednak różne ze względu na to, że obsługują różne silniki, czyli zakresy obrotu danego silnika-ile pulsów w lewo, a ile w prawo, prędkość przemieszczenia, kąt przemieszczenia (na razie w pulsach enkodera).
Poniżej prezentuję krótki filmik, jak działa samo sterowanie:
Link

Jeśli będziecie zainteresowani, to rozwinę ten temat dalej. Na razie to tyle.

krolikbest napisał:

ale ostatecznie zdecydowałem się na nietypową architekturę. Główną jednostką jest Raspberry Pi ver.3 na którym działa mój program napisany w Lazarusie (Object Pascal).

Ciekawe podejście. A jak wygląda u Ciebie praktycznie kwestia kompilacji, tzn. czy masz IDE Lazarusa na tej malince, czy tylko kompilator FP a źródła piszesz gdzieś "z boku"?

Lazarus jest zainstalowany na tej Malince ver 1.7

Czyli masz podłączony do maliny monitor, klawiaturę mysz i robisz na niej komplet pracy tzn. kompilację, wizualizację itd. . Bez angażowania żadnego innego sprzętu.
Dobrze rozumiem?

Dokładnie tak. Pisanie poza Maliną lekko mija się z celem ponieważ korzystam z bibliotek na Malinę. Chociaż napisanie programiku opartego na standardowych komponentach IDE Lazarusa w Windowsie i skompilowanie go do architektury ARM/Linux testowałem i potwierdzam że uruchamia się taki program na RPi.

krolikbest napisał:

Dokładnie tak. Pisanie poza Maliną lekko mija się z celem ponieważ korzystam z bibliotek na Malinę.

Przyjrzałem się tak na spokojnie Twoim filmikom i powiązanym materiałom i stwierdzam że pokazałeś bardzo intrygujące, jak dla mnie, perspektywy tutaj tą publikacją. Czyli temat sterowników programowanych solidnymi i przyjaznymi pascalopochodnymi narzędziami. A widzę teraz że w tym temacie są spore zasoby różnych fajnych rzeczy. Tak że wielkie dzięki.

A konkretnie do Twojego projektu, to mam takie trochę obawy, czy akurat I2C jest optymalnym wyborem dla tego rodzaju konstrukcji. Jak dla mnie, to akurat ten standard, niesie z sobą pewne kłopoty, jak m.in. dość realna możliwość "zakleszczenia" magistrali, przy różnych sytuacjach (np. resetowanie mastera w momencie transmisji ze slave bitu o wartości 0 ). Oczywiście da się to ogarnąć ale nie czuję jakieś znaczącej przesłanki stosowania akurat tutaj I2C (skoro i tak po drugiej stronie są AVR, które i tak trzeba oprogramować), wobec nawet prostej komunikacji szeregowej opartej na prostym protokole lub klasycznych rozwiązaniach.

Faktycznie co do i2c to mam ciągle pod górkę. Wybrałem ten protokół nieco z ciekawości, jednak inaczej wszystko wygląda z pozycji biurka doświadczalnego w zacisznym "kąciku badawczym" -tutaj wszystko pracuje elegancko, a testowaniem urządzenia na hali produkcyjnej z pracującymi spawarkami, czy maszyny z silnikami 22KW, gdzie zakłócenia na linii zasilającej są duże i niestety przenoszą się na łącze i2c. Mam nadzieję, że temat zakłóceń ogarnę wkrótce. Co do standardowego protokołu komunikacji szeregowej to chyba masz rację. Jest znany, dużo projektów mam na nim oparte, ale tak to jest, że poznając coś nowego, "frycowe" trzeba zapłacić

Może po długim łykendzie uda mi się pokazać filmik z ruchomym ramieniem.

Pozdrawiam,
Marcin

Jakie jest przeznaczenie tego ramienia?

Generalnie chodzi o:
- napisanie niezawodnego systemu sterującego napędami w tej konfiguracji jaką wybrałem, czyli RPi "gada" z atmegami po i2c
- stworzenie algorytmu do sterowania w trybie
a). poruszania ramieniem robota i zaznaczania punktów w przestrzeni tworzących ścieżkę jego przebiegu,
b). zaprojektowanie aplikacji w której będzie można określić na płaszczyźnie (osie XZ) jakiś punkt do którego ramię powinno dążyć (to jest na moim filmiku
tutaj).

Faza 3

Link

Nie mam jeszcze ukończonego algorytmu nauki ruchu robota, ale jestem w trakcie pisania.
Ramiona robota są wykonane z drewna, napędzane przez pięć silników hybrid-servo, sygnały krok/kierunek oraz odczyty enkoderów to zajęcie atmeg8. Udało się w miarę zgrać współpracę Maliny z atmegami po protokole i2c, ale dla profesjonalnego wykorzystania zastosuję jednak interfejs rs485.

W końcu dopisałem moduł uczenia manipulatora. Wygląda to tak, że po osiągnięciu jakiegoś żądanego punktu w przestrzeni, zapisujemy wartość enkoderów, przesuwamy do kolejnego punktu i czynność powtarzamy. Na koniec możemy powrócić do pozycji startowej (Home). Taką siatkę złożoną z wartości poszczególnych enkoderów zapisujemy do pliku. Aby wykonać taki plik ustawiamy ramie w pozycji startowej ( w takiej w jakiej zaczynaliśmy naukę w tym konkretnym przypadku) i uruchamiamy wykonanie skryptu. Malinka wysyła dane do poszczególnych mikrokontrolerów a te wykonują przesłane zadania. Poniżej zamieszczam film z przykładowym uczeniem ramienia: nauka robota

Pozdrawiam,

Marcin