Міжпроцесорний зв'язок для роботизованої руки


13

Я будую хобі-6-DOF-робототехнічну руку і мені цікаво, який найкращий спосіб - це спілкування між процесорами (3-4 AVR, 18 дюймів максимум поділу). Мені б хотілося, щоб на комп'ютері працював цикл управління, який надсилає команди мікропроцесорам через USB-інтерфейс Atmega32u4 - ??? міст.

Деякі ідеї, які я розглядаю:

  1. RS485
    • Плюси: всі процесори на одному дроті, диференціальний сигнал більш надійний
    • Мінуси: потрібні додаткові мікросхеми, потрібно написати (або знайти?) Протокол, щоб запобігти передачі процесорів одночасно
  2. Цикл UART (тобто TX одного процесора підключений до RX наступного)
    • Плюси: проста прошивка, в процесори є вбудований UART
    • Мінуси: останнє з'єднання має проходити довжину робота, кожен процесор повинен витрачати цикли на повторну передачу повідомлень
  3. CANbus (я дуже мало про це знаю)

Мої основні міркування - складність апаратного забезпечення та вбудованого програмного забезпечення, продуктивність та ціна (я не можу придбати дорогу нестандартну систему).

Відповіді:


13

Ви хочете використовувати USB для зв'язку з комп'ютером. Якщо у вас є декілька мікроконтролерів, ви, ймовірно, підключите лише один з мікроконтролерів безпосередньо до комп'ютера. Іншим мікроконтролерам потрібно буде отримати свої команди від основного мікроконтролера.

Вибір спілкування залежатиме від ряду факторів:

  • необхідна пропускна здатність (будемо вважати, що ви працюєте на них 16 МГц)
  • складність (проводка та кодування)
  • двонаправлений, або господар-раб

Майже у всіх опціях є вбудована підтримка мікроконтролера AVR. Немає жодної опції, яку ви могли б віддати перевагу над вбудованими параметрами, які потребували б додаткового обладнання. Оскільки у них є вбудована підтримка, складність програмного забезпечення схожа на те, що ви просто налаштовуєте порт (використовуючи регістри), ставите дані для передачі в інший реєстр, а потім запускаєте передачу, встановивши трохи в інший реєстр. Будь-які отримані дані знаходяться в іншому реєстрі, і спрацьовує переривання, щоб ви могли обробляти його. Який би варіант ви не вибрали, єдиною різницею є зміна розташування реєстрів та деякі зміни регістрів конфігурації.


Цикл USART має такі функції:

  • Максимальна швидкість передачі сигналу CLK / 16 = 1 МГц (при тактовій частоті 16 МГц), що є швидкістю передачі близько 90 КБ / с.
  • повністю двонаправлені комунікації (без позначення головного чи підлеглого)
  • потрібні окремі дроти між кожною парою мікроконтролерів - Atmega32u4 підтримує два порти USART спочатку, обмежуючи кількість мікроконтролерів, до яких ви можете підключитись у мережі на практиці (інакше у вас є довга струна мікроконтролерів - тобто підключена у зв'язаний список спосіб)

Примітка: це також те, що ви використовували б для отримання зв'язку RS232, за винятком того, що, оскільки RS232 вимагає 10В, він вимагає, щоб драйвер отримував ці рівні напруги. Для зв'язку між мікроконтролерами це не корисно (змінюються лише рівні напруги).

RS485:

  • По суті, ви використовуєте порт USART в іншому режимі - немає переваги в пропускній здатності, і це може лише спростити електропроводку, але це також ускладнить її. Це не рекомендується.

Двопровідний інтерфейс:

  • Це також називається I2C. Це означає, що всі пристрої мають однакові два дроти.

  • Вам потрібен підтягуючий резистор обох проводів

  • Це повільно (оскільки резистори, що підтягуються, мають обмежене значення, а ємність збільшується, оскільки кількість пристроїв збільшується, а довжина проводу збільшується). Для цього мікроконтролера AVR швидкість до 400 кГц - повільніше, ніж USART (але ця швидкість залежить від обмеження вашої ємності). Причина полягає в тому, що, хоча пристрій приводить низький провід даних, протилежний перехід здійснюється, дозволяючи проводу знову плисти високо (підтягуючий резистор).

  • Це ще повільніше, якщо врахувати, що ВСІ комунікації мають однакову обмежену пропускну здатність. Оскільки всі комунікації мають однакову обмежену пропускну здатність, можливі затримки в спілкуванні, коли дані повинні чекати, поки мережа не працює, перш ніж її можна буде надіслати. Якщо інші дані постійно надсилаються, вони також можуть блокувати їх надсилання.

  • Він покладається на протокол master-slave, де ведучий звертається до підлеглого, потім надсилає команду / запит, а підлеглий відповідає після цього. Одночасно може спілкуватися лише один пристрій, тому раб повинен чекати, коли господар закінчить.

  • Будь-який пристрій може виступати як господарем і / або рабом, що робить його досить гнучким.

SPI

  • Це я б рекомендував / використовував для загальної комунікації між мікроконтролерами.

  • Це висока швидкість - до CLK / 2 = 8 МГц (для CLK на 16 МГц), що робить його найшвидшим методом. Це досягається завдяки окремому дроту виключно для годинника.

  • Дані MOSI, MISO та тактові годинники SCK поділяються по всій мережі, а це означає, що вона має більш просту проводку.

  • Це формат "ведучий-ведений", але будь-який пристрій може бути ведучим та / або підлеглому. Однак через ускладнення вибору підлеглого для спільного проводки (всередині мережі) слід використовувати його тільки в ієрархічному порядку (на відміну від двопровідного інтерфейсу). IE. якщо ви впорядковуєте всі пристрої на дереві, пристрій повинен бути господарем лише своїх дітей і лише рабом свого батька. Це означає, що в рабовласницькому режимі пристрій завжди матиме одного і того ж ведучого. Крім того, щоб зробити це правильно, вам потрібно додати резистори до MISO / MOSI / SCK до ведучого верхового потоку, так що якщо пристрій передаватиметься за низхідним потоком (коли не вибрано як підлеглий), зв’язок не вплине на комунікації в інших частинах мережа (зауважте, кількість рівнів, які ви можете зробити за допомогою резисторів обмежена, див. нижче для кращого рішення з використанням обох портів SPI).

    Мікроконтролер AVR може автоматично тривиходити сигнал MOSI, коли він обраний веденим, і перейти в ведений режим (якщо він є головним).

    Хоча це може потребувати ієрархічної мережі, більшість мереж можуть бути організовані у вигляді дерева, тому це, як правило, не є важливим обмеженням

  • Вищезазначене можна злегка розслабити, оскільки кожен мікроконтролер AVR підтримує два окремі порти SPI, тому кожен пристрій може мати різні позиції у двох різних мережах.

    Сказавши це, якщо вам потрібно багато рівнів у вашому дереві / ієрархії (більше 2), вищевказане рішення з використанням резисторів надто хитро працює. У цьому випадку слід змінити мережу SPI між кожним шаром дерева. Це означає, що кожен пристрій підключатиметься до своїх дітей в одній мережі SPI, а його батько - в іншій мережі SPI. Хоча це означає, що у вас є лише одне дерево з'єднань, перевага полягає в тому, що пристрій може одночасно спілкуватися як з одним зі своїх дітей, так і з його батьком, і у вас немає чітко виражених резисторів (завжди важко вибрати правильні значення) .

  • Оскільки у нього є окремі проводки MOSI і MISO, одночасно і головний, і ведений можуть спілкуватися, надаючи йому потенційний фактор у два збільшення швидкості. Додатковий штифт потрібен для вибору рабовласників для кожного додаткового раба, але це не є великим тягарем, навіть 10 різних рабів потребують лише 10 додаткових штифтів, які можна легко розмістити на типовому мікроконтролері AVR.

CAN не підтримується вказаним вами мікроконтролером AVR. Оскільки є й інші хороші варіанти, це, мабуть, у цьому випадку все одно не важливо.


Рекомендація - SPI , оскільки це швидко, проводка не надто складна і не потребує прискіпливих резисторів. У рідкісному випадку, коли SPI не повністю відповідає вашим потребам (можливо, у складніших мережах), ви можете використовувати кілька варіантів (наприклад, використовувати обидва порти SPI разом із двопровідним інтерфейсом, а також спарити деякі мікроконтролери використовуючи цикл USART!)

У вашому випадку використання SPI означає, що, природно, мікроконтролер з USB-підключенням до комп'ютера може бути головним, і він може просто переслати відповідні команди з комп'ютера на кожен підлеглий пристрій. Він також може читати оновлення / вимірювання від кожного підлеглого і надсилати їх на комп'ютер.

При довжині дроту 8 МГц і 0,5 м, я не думаю, що це стане проблемою. Але якщо це так, постарайтеся бути більш уважними до ємності (тримайте заземлення та сигнальні дроти надто близько, а також будьте обережні щодо з'єднань між різними провідниками), а також припинення сигналу. У тому випадку, коли це залишається проблемою, ви можете зменшити тактову частоту, але я не вважаю це необхідним.


Великі пальці на SPI у мене
georgebrindeiro

2
Я теж шанувальник SPI, хоча, можливо, I2C також варто розглянути (уникає необхідності окремих окремих ліній CS до кожного пристрою). Але CAN не можна так легко звільняти - зрештою, це автомобільний автобус вибору, тому я б не виключав цього з хобі-робототехніки!
Андрій

Чи справді шині SPI потрібні окремі лінії CS від головного до кожного підлеглого? Якщо так, то як би ви назвали ту іншу шину, яка вимагає рівно 4 підключень до ведучого, незалежно від того, скільки підключених рабів, про що йдеться у статті Вікіпедії на шині SPI ?
Девід Кері

1
+1 Для величезної реакції я старий школяр і люблю 485 і взагалі автобуси з програмною адресою, але в цьому випадку компоненти швидкості та споживання ресурсів я б обрав SPI. Хоча ви б приділили великій увазі відстані та електричному шуму, особливо якщо шина поєднує інші ІМС з різною швидкістю передачі: пам’яті, NIC тощо, які можуть зазнати помаранчування та амплітуди втрат годин
RTOSkit

3
Ваші коментарі щодо CAN не точні. CAN - це не будь-яка двожильна шина. Я думаю, ви плутаєте це з I2C, який має максимальну швидкість 400 кбіт / с. Максимальна швидкість CAN - 1 Мбіт / с.
Rocketmagnet

5

Я настійно рекомендую CAN для міжпроцесорних комунікацій. Ми використовуємо це в наших роботах, з до 22 процесорами на одній шині. При хорошому дизайні протоколу ви можете використовувати близько 90% доступної пропускної здатності (близько 640 кбіт / с, якщо врахувати всю перевірку помилок та міжкадровий інтервал). Ми можемо обслуговувати 10 двигунів при 1000 Гц на одній шині CAN. Це наближається до межі. Можливо, ви могли б стиснути його до 20 двигунів, якщо ви дуже ретельно запакуєте дані.

Взагалі CAN повинен мати по одному мікросхемі приймача для кожного процесора (це лише невеликий 8-контактний пристрій). Приймач приймає приємний диференціальний сигнал, який випромінює дуже мало перешкод, а також робить його несприйнятливим до перешкод, якщо ви працюєте в електрично галасливому середовищі (двигуни, соленоїди та радіопередавачі).

CAN-з'єднання

Однак в обмежених обставинах реально використовувати CAN без трансиверів .


EtherCAT

Якщо ви коли-небудь захочете реалізувати шину з серйозною пропускною здатністю, пропоную спробувати EtherCAT . Це шина 100 Мб, яку можна підключити до порту Ethernet вашого ПК. До автобуса є дві важливі частини:

  • Міст. Це перетворює фізичний шар Ethernet в більш простий фізичний рівень LVDS, що не вимагає великих роз'ємів, Phy чіпа та багатьох компонентів, які сам Ethernet робить.
  • Вузли. Кожен вузол просто потребує одного мікросхеми ET1200 та мікроконтролера.

Комп'ютер може передавати та приймати великі куски даних до та з вузлів з частотою 1 кГц або швидше. Ви можете керувати досить багато матеріалів на одній шині EtherCAT.

Додано:

Компанія Shadow Robot тепер продає корисну систему EtherCAT Bus під назвою Ronex . Це дозволяє вам додавати досить багато вводу-виводу, і вони незабаром представлятимуть безліч інших типів плати, як контролери двигуна та високоякісні АЦП.


Яке джерело для цього зображення? Він має CAN Highяк для червоного, так і для синього проводів.
Ян

1

Я знаю, що я копаю стару тему, і це щось на відміну від теми, але я не думаю, що ви можете просто взяти чіп ET1200 від Beckhoff. Я трохи відправив їх по електронній пошті назад і мені порадили, що мені потрібно приєднатися до групи Ethercat. Для цього мені довелося продемонструвати, що я збираюся внести свій внесок у групу - тобто, будуючи та продаючи пристрої, які використовують речі Ethercat. У цей (і цей) момент часу я все ще прототипую свій пристрій (безщітковий контролер двигуна для програм-роботів - наразі використовую CAN), тому я нічого не міг запропонувати (я не можу дати надійний час на завершення - я все ще працюю над своїм недоград). Я висловив їм своє розчарування. Вони сказали не розчаровуватися !! Досить смішні речі! Я б справділюблять потрапляти в Ethercat, але ASIC, здається, недоторканні для любителів чи тих, хто не має компанії. Крім того, це мій перший пост, тож вибачте, якщо я розгнівав богів, викопавши старий пост!


Ласкаво просимо. Відновлення старої публікації чудово, якщо відповідь актуальна. І ваш коментар здається мені актуальним ...
Андрій

Дякую, друже. Це чудовий форум! Не цікаво, чи маєте ви досвід роботи з Ethercat? Чи знаєте ви які-небудь інші методи отримання підлеглого пристрою, придатного для прототипування на друкованих плат? Я готовий платити, але на даний момент я просто не відповідають вимогам приєднатися до групи, щоб придбати ASIC Bechoff. Розчарування!
закон

Не EtherCat, ні. Я використовую CAN (хороший варіант), LIN (не дуже хороший IMHO) і, безумовно, можна рекомендувати SPI або I2C
Andrew

Чи вдалося вам влаштувати чіп ET1100 або ET1200? Якщо ви цього не зробили, зараз є інший варіант: мікрочіп LAN9252, він сумісний з ET1100 і працює досить добре. Використовуйте бібліотеку
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.