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


13

Я создаю увлекательную роботизированную руку с 6 степенями свободы, и мне интересно, как лучше общаться между процессорами (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 (но эта скорость зависит от ограничения вашей емкости). Причина в том, что, хотя устройство управляет проводом передачи данных на низком уровне, обратный переход достигается путем повторного всплытия провода (нагрузочный резистор).

  • Это даже медленнее, если учесть, что ВСЕ коммуникации имеют одинаковую ограниченную пропускную способность. Поскольку все коммуникации имеют одинаковую ограниченную пропускную способность, могут возникнуть задержки в связи, когда данные должны ждать, пока сеть не будет свободна, прежде чем ее можно будет отправить. Если другие данные постоянно отправляются, они также могут заблокировать отправку данных.

  • Он полагается на протокол «ведущий-ведомый», где ведущий обращается к ведомому, затем отправляет команду / запрос, а затем подчиненный отвечает. Только одно устройство может обмениваться данными одновременно, поэтому ведомое устройство должно ждать завершения работы мастера.

  • Любое устройство может выступать как ведущим, так и / или подчиненным, что делает его довольно гибким.

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. Хотя вы будете уделять большое внимание расстоянию и электрическим помехам, особенно если ваша шина совместима с другими микросхемами с разной скоростью передачи: памяти, сетевыми картами и т. Д.,
Которые

3
Ваши комментарии по CAN не точны. CAN - это не просто двухпроводная шина. Я думаю, что вы путаете это с I2C, который имеет максимальную скорость 400 кбит / с. Максимальная скорость CAN составляет 1 Мбит / с.
Ракетный магнит

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
Эндрю

Вам удалось заполучить чип ET1100 или ET1200? Если у вас нет другой опции, доступной сейчас: микрочип LAN9252, он совместим с ET1100 и работает довольно хорошо. С уважением,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.