Komunikacja między procesorami dla ramienia robota


13

Buduję hobby robotyczne ramię 6-DOF i zastanawiam się, jaki jest najlepszy sposób komunikacji między procesorami (3-4 AVR, maks. 18 cali separacji). Chciałbym mieć uruchomioną pętlę sterowania na komputerze, który wysyła polecenia do mikroprocesorów za pośrednictwem złącza USB Atmega32u4 do - ??? most.

Kilka pomysłów, które rozważam:

  1. RS485
    • Plusy: wszystkie procesory na tym samym przewodzie, sygnał różnicowy bardziej niezawodny
    • Minusy: wymaga dodatkowych układów, musisz napisać (lub znaleźć?) Protokół, aby uniemożliwić procesorom jednoczesną transmisję
  2. Pętla UART (tzn. TX jednego procesora jest podłączony do RX następnego)
    • Plusy: proste oprogramowanie, procesory mają wbudowane UART
    • Minusy: ostatnie połączenie musi pokonać długość robota, każdy procesor musi spędzić cykle retransmisji wiadomości
  3. CANbus (niewiele o tym wiem)

Moje główne uwagi to złożoność sprzętu i oprogramowania układowego, wydajność i cena (nie mogę kupić drogiego, gotowego do użycia systemu).

Odpowiedzi:


13

Chcesz używać USB do komunikacji z komputerem. Jeśli masz wiele mikrokontrolerów, prawdopodobnie tylko jeden z mikrokontrolerów zostanie podłączony bezpośrednio do komputera. Pozostałe mikrokontrolery będą musiały uzyskać polecenia z głównego mikrokontrolera.

Wybór komunikacji zależy od wielu czynników:

  • wymagana przepustowość (założymy, że używasz ich z częstotliwością 16 MHz)
  • złożoność (okablowanie i kodowanie)
  • dwukierunkowy lub master-slave

Prawie wszystkie opcje mają wbudowaną obsługę mikrokontrolera AVR. Nie ma opcji, która mogłaby być rozsądniejsza niż opcje wbudowane, które wymagałyby dodatkowego sprzętu. Ponieważ mają one wbudowaną obsługę, złożoność oprogramowania jest podobna, ponieważ wystarczy skonfigurować port (za pomocą rejestrów), umieścić dane do przesłania do innego rejestru, a następnie uruchomić transmisję, ustawiając bit w innym rejestrze. Wszelkie otrzymane dane znajdują się w innym rejestrze i uruchamiane jest przerwanie, abyś mógł je obsłużyć. Niezależnie od wybranej opcji, jedyną różnicą jest zmiana lokalizacji rejestrów i pewne zmiany w rejestrach konfiguracji.


Pętla USART ma następujące funkcje:

  • Maksymalna prędkość transmisji CLK / 16 = 1 MHz (przy zegarze 16 MHz), co oznacza szybkość transferu około 90 KB / s
  • w pełni dwukierunkowa komunikacja (bez oznaczenia master lub slave)
  • wymaga osobnych przewodów między każdą parą mikrokontrolerów - Atmega32u4 obsługuje natywnie dwa porty USART, ograniczając liczbę mikrokontrolerów, które można podłączyć w sieci w praktyce (lub w końcu otrzymujesz długi ciąg mikrokontrolerów - tj. połączonych na połączonej liście sposób)

Uwaga: tego też byś użył do uzyskania komunikacji RS232, z wyjątkiem tego, że ponieważ RS232 wymaga 10 V, to wymaga sterownika, aby uzyskać te poziomy napięcia. W przypadku komunikacji między mikrokontrolerami nie jest to przydatne (zmieniane są tylko poziomy napięcia).

RS485:

  • Zasadniczo używasz portu USART w innym trybie - nie ma przewagi w zakresie przepustowości i może to tylko nieco uprościć okablowanie, ale także to komplikuje. Nie jest to zalecane.

Interfejs dwuprzewodowy:

  • Jest to również określane jako I2C. Oznacza to, że wszystkie urządzenia mają te same dwa przewody.

  • Potrzebujesz rezystora podciągającego na obu przewodach

  • Jest wolny (ponieważ rezystory podciągające mają ograniczoną wartość, a pojemność rośnie wraz ze wzrostem liczby urządzeń i wzrostem długości drutu). W przypadku tego mikrokontrolera AVR prędkość wynosi do 400 kHz - wolniej niż w USART (ale ta prędkość zależy od ograniczenia pojemności). Powodem jest to, że chociaż urządzenie wprawia przewód danych w stan niski, przejście przeciwne uzyskuje się, pozwalając drutowi ponownie unieść się wysoko (rezystor podciągający).

  • Jest jeszcze wolniejszy, jeśli weźmiesz pod uwagę, że WSZYSTKIE połączenia mają tę samą ograniczoną przepustowość. Ponieważ cała komunikacja ma tę samą ograniczoną szerokość pasma, mogą wystąpić opóźnienia w komunikacji, w których dane muszą poczekać, aż sieć będzie bezczynna, zanim będzie mogła zostać wysłana. Jeśli ciągle wysyłane są inne dane, może to również uniemożliwić przesyłanie danych.

  • Opiera się na protokole master-slave, w którym master adresuje slave, a następnie wysyła polecenie / żądanie, a następnie slave odpowiada. Jednocześnie może komunikować się tylko jedno urządzenie, więc urządzenie podrzędne musi czekać na zakończenie pracy urządzenia nadrzędnego.

  • Każde urządzenie może działać zarówno jako master i / lub slave, co czyni go dość elastycznym.

SPI

  • Właśnie to poleciłbym / wykorzystał do ogólnej komunikacji między mikrokontrolerami.

  • Jest szybki - do CLK / 2 = 8 MHz (dla CLK przy 16 MHz), co czyni go najszybszą metodą. Jest to możliwe dzięki oddzielnemu przewodowi wyłącznie do zegara.

  • Przewody danych MOSI, MISO i SCK są współdzielone w całej sieci, co oznacza, że ​​ma prostsze okablowanie.

  • Jest to format master-slave, ale każde urządzenie może być master i / lub slave. Jednak ze względu na komplikacje związane z wyborem urządzenia podrzędnego w przypadku współdzielonego okablowania (w sieci) należy go używać tylko w sposób hierarchiczny (w przeciwieństwie do interfejsu dwuprzewodowego). TO ZNACZY. jeśli wszystkie urządzenia zostaną zorganizowane w drzewo, urządzenie powinno być nadrzędne tylko dla swoich dzieci, a tylko dla swojego rodzica. Oznacza to, że w trybie slave urządzenie zawsze będzie miało ten sam master. Ponadto, aby to zrobić poprawnie, należy dodać rezystory do MISO / MOSI / SCK do nadrzędnego urządzenia nadrzędnego, aby jeśli urządzenie komunikowało się za urządzeniem (gdy nie zostało wybrane jako urządzenie podrzędne), komunikacja nie wpłynie na komunikację w innych częściach sieć (należy pamiętać, że liczba poziomów, które można to zrobić za pomocą rezystorów jest ograniczona, patrz poniżej, aby uzyskać lepsze rozwiązanie przy użyciu obu portów SPI).

    Mikrokontroler AVR może automatycznie potrójnie sygnalizować sygnał MOSI po wybraniu urządzenia podrzędnego i przejść do trybu podrzędnego (jeśli jest w trybie głównym).

    Chociaż może to wymagać sieci hierarchicznej, większość sieci może być zorganizowana w sposób drzewiasty, więc zwykle nie jest to istotne ograniczenie

  • Powyższe można nieco złagodzić, ponieważ każdy mikrokontroler AVR obsługuje dwa oddzielne porty SPI, dzięki czemu każde urządzenie może mieć różne pozycje w dwóch różnych sieciach.

    Powiedziawszy to, jeśli potrzebujesz wielu poziomów w swoim drzewie / hierarchii (więcej niż 2), powyższe rozwiązanie wykorzystujące rezystory staje się zbyt skomplikowane, aby działać. W takim przypadku należy zmienić sieć SPI między każdą warstwą drzewa. Oznacza to, że każde urządzenie połączy się ze swoimi dziećmi w jednej sieci SPI, a nadrzędnym w drugiej sieci SPI. Chociaż oznacza to, że masz tylko jedno drzewo połączeń, zaletą jest to, że urządzenie może komunikować się zarówno z jednym z jego dzieci, jak i nadrzędnym w tym samym czasie i nie masz skrzypcowych rezystorów (zawsze trudno jest wybrać odpowiednie wartości) .

  • Ponieważ ma oddzielne przewody MOSI i MISO, zarówno master, jak i slave mogą komunikować się w tym samym czasie, co daje potencjalny czynnik dwukrotnego wzrostu prędkości. Dodatkowy pin jest wymagany do wyboru slave dla każdego dodatkowego slave, ale nie jest to duże obciążenie, nawet 10 różnych slave wymaga tylko 10 dodatkowych pinów, które można łatwo pomieścić na typowym mikrokontrolerze AVR.

CAN nie jest obsługiwany przez określony mikrokontroler AVR. Ponieważ istnieją inne dobre opcje, w tym przypadku prawdopodobnie nie jest to ważne.


Zaleca się SPI , ponieważ jest szybki, okablowanie nie jest zbyt skomplikowane i nie wymaga skomplikowanych rezystorów podciągających. W rzadkim przypadku, gdy SPI nie w pełni spełnia twoje potrzeby (prawdopodobnie w bardziej skomplikowanych sieciach), możesz użyć wielu opcji (np. Użyć obu portów SPI, wraz z interfejsem dwuprzewodowym, a także sparować niektóre mikrokontrolery za pomocą pętli USART!)

W twoim przypadku użycie SPI oznacza, że ​​oczywiście mikrokontroler z połączeniem USB do komputera może być nadrzędny i może po prostu przesłać odpowiednie polecenia z komputera do każdego urządzenia podrzędnego. Może również odczytać aktualizacje / pomiary z każdego urządzenia podrzędnego i wysłać je do komputera.

Przy 8 MHz i 0,5 m długości drutu nie sądzę, że stanie się to problemem. Ale jeśli tak jest, staraj się bardziej uważać na pojemność (utrzymuj uziemienie i przewody sygnałowe zbyt blisko, a także uważaj na połączenia między różnymi przewodami), a także na zakończenie sygnału. W mało prawdopodobnym przypadku, gdy problem nadal występuje, możesz zmniejszyć częstotliwość taktowania, ale nie sądzę, aby było to konieczne.


Kciuki w górę za SPI ode mnie
georgebrindeiro

2
Jestem też fanem SPI, choć być może warto też rozważyć I2C (pozwala to uniknąć oddzielnych linii CS do każdego urządzenia). CAN nie należy jednak tak łatwo odrzucić - w końcu jest to autobus z wyboru, więc nie wykluczałbym roboty robotyki!
Andrew

Czy magistrala SPI naprawdę wymaga oddzielnych linii CS od urządzenia nadrzędnego do każdego urządzenia podrzędnego? Jeśli tak, jak nazwałbyś tę inną magistralę, która wymaga dokładnie 4 połączeń z masterem, bez względu na liczbę podłączonych slaveów, o czym wspomniano w artykule Wikipedii na temat magistrali SPI ?
David Cary,

1
+1 Za ogromną odpowiedź, jestem oldschoolowy i uwielbiam 485 i ogólnie autobusy z adresem oprogramowania, ale w tym przypadku, komponenty prędkości i zużycia zasobów, wybrałbym SPI. Chociaż dużo uwagi poświęcasz odległości i zakłóceniom elektrycznym, zwłaszcza jeśli twój autobus współistnieje z innymi układami scalonymi o różnych prędkościach transmisji: pamięci, karta sieciowa itp., Które mogą ucierpieć z powodu awarii i amplitudy utraty zegara
RTOSkit

3
Twoje komentarze na temat CAN nie są dokładne. CAN to nie tylko 2-żyłowa magistrala. Myślę, że mylisz go z I2C, który ma maksymalną prędkość 400 kb / s. Maksymalna prędkość CAN to 1 Mb / s.
Rocketmagnet

5

Mogę bardzo polecić CAN do komunikacji między procesorami. Używamy go w naszych robotach, z maksymalnie 22 procesorami w tej samej magistrali. Przy dobrym projekcie protokołu możesz zużyć około 90% dostępnej przepustowości (około 640 kb / s, jeśli weźmiesz pod uwagę wszystkie sprawdzanie błędów i odstępy między ramkami). Jesteśmy w stanie obsłużyć 10 silników przy 1000 Hz na jednej magistrali CAN. To zbliża się do limitu. Prawdopodobnie możesz ścisnąć go do 20 silników, jeśli bardzo starannie zapakujesz dane.

Zasadniczo CAN musi mieć jeden układ nadawczo-odbiorczy dla każdego procesora (to tylko małe 8-stykowe urządzenie). Transceiver zapewnia ładny sygnał różnicowy, który emituje bardzo mało zakłóceń, a także czyni go odpornym na zakłócenia, jeśli pracujesz w hałaśliwym otoczeniu elektrycznym (silniki, elektromagnesy i nadajniki radiowe).

Połączenia magistrali CAN

Jednak w ograniczonych okolicznościach możliwe jest użycie CAN bez nadajników-odbiorników .


EtherCAT

Jeśli kiedykolwiek masz ochotę wdrożyć magistralę o dużej przepustowości, sugeruję wypróbowanie EtherCAT . Jest to magistrala 100 Mb, którą można podłączyć do portu Ethernet komputera. Autobus ma dwie ważne części:

  • Most Konwertuje to warstwę fizyczną Ethernet na prostszą, tańszą warstwę fizyczną LVDS, która nie wymaga dużych złączy, układu Phy i wielu komponentów, które robi sam Ethernet.
  • Węzły Każdy węzeł potrzebuje tylko jednego układu ET1200 i mikrokontrolera.

Komputer może przesyłać i odbierać duże porcje danych do iz węzłów z częstotliwością 1 kHz lub większą. Możesz kontrolować całkiem sporo rzeczy na jednej magistrali EtherCAT.

Dodany:

Shadow Robot Company sprzedaje teraz przydatny system magistrali EtherCAT o nazwie Ronex . Pozwala dodać całkiem sporo I / O, a oni wkrótce wprowadzą wiele innych typów kart, takich jak sterowniki silników i wysokiej jakości przetworniki ADC.


Jakie jest źródło tego obrazu? Ma CAN Highzarówno czerwone, jak i niebieskie przewody.
Ian

1

Wiem, że wykopuję stary wątek i to trochę nie na temat, ale nie sądzę, że możesz po prostu zdobyć układy ET1200 od Beckhoffa. Niedawno wysłałem im e-mailem i doradzono mi, że muszę dołączyć do grupy Ethercat. Aby to zrobić, musiałem wykazać, że wrócę do grupy - tj. Budując i sprzedając urządzenia wykorzystujące produkty Ethercat. W tym (i tym) momencie wciąż prototypuję swoje urządzenie (bezszczotkowy sterownik silnika do aplikacji robotów - obecnie używam CAN), więc nie mogłem nic zaoferować (nie mogę dać solidnego czasu na ukończenie - Nadal pracuję nad moim undergrad). Wyraziłem dla nich moje rozczarowanie. Mówili, żeby nie być rozczarowanym !! Całkiem śmieszne rzeczy! Chciałbym naprawdęlubią dostać się do Ethercat, ale ASIC wydają się nietykalne dla hobbystów lub osób bez firmy. To także mój pierwszy post, więc przepraszam, że rozgniewałem bogów, wykopując stary post!


Witamy. Wskrzeszenie starego postu jest w porządku, jeśli odpowiedź jest istotna. A twój komentarz wydaje mi się odpowiedni ...
Andrew

Dzięki stary. To jest świetne forum! Czy poza zainteresowaniem masz jakieś doświadczenie z Ethercat? Czy znasz jakieś inne metody uzyskania urządzenia podrzędnego odpowiedniego do prototypowania na płytkach drukowanych? Jestem gotów zapłacić, ale w tej chwili po prostu nie spełniam wymagań, aby dołączyć do grupy, aby kupić układy ASIC firmy Bechoff. Denerwujący!
ustawa z

Nie EtherCat, nie. Używam CAN (dobra opcja), LIN (niezbyt dobre IMHO) i na pewno mogę polecić SPI lub I2C
Andrew

Czy udało Ci się zatrzymać układ ET1100 lub ET1200? Jeśli tego nie zrobiłeś, dostępna jest teraz inna opcja: microchip LAN9252, jest kompatybilny z ET1100 i działa całkiem dobrze. Skorzystaj z biblioteki SOES
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.