Замена rc-серво-протокола


Пока всего лишь некоторые мысли о том каким должен быть протокол и интерфейс к сервам и другим контроллерам двигателей. Пишу чтобы послушать критику, предложения по улучшению.



Не буду говорить о недостатках RC-PWM протокола, и почему не I2C который уже используется например в OpenServo. Думаю это все станет ясно позже.

Предлагаемый интерфейс это UART. От сервы идут четыре провода, VCC/GND и RX/TX. Все просто. После подачи питания инициализируется работа на скорости скажем 9600. В этом режиме доступен шелл, для конфигурения, диагностики, настройки. Что там можно конфигурить/делать? Скорость uart, параметры регулятора, подергать контроллер и посмотреть на то как оно работает, адрес устройства.

Второй режим это бинарный протокол для управления сетью slave устройств. Схема подключения следующая, на примере трех устройств.



Диоды и подтяг ставятся рядом с RX, так что через резистор происходит заряд только емкости диодов а не всех проводов.

У каждого устройства свой адрес, точнее даже это не адрес а номер конечной точки, у одного устройства их может быть две или более. Все операции инициируются управляющим устройством. Формат передачи пакета.



Что будет в payload определяется номером конечной точки. То есть если мы что-то куда-то посылаем, то надо знать какое там устройство и что оно принимает. Для сервы можно например так.



В S можно положить контрольную сумму, можно ничего.

Номер конечной точки определяет не только формат пакета но и наличение/отсутсвие ответа. Сам процесс ответа выглядит следующим образом.



Серва видит пакет с единицей в старшем бите и совпадение адреса со своим. Запускает отправку ответа. В ответе идет тот же номер конечной точки этой сервы и любые данные, на картинке для примера передается угол.

Как можно догадаться этот протокол приспособлен для использования DMA. Формируем массив со всеми пакетами и включаем передачу. По окончанию имеем принятый массив ответных пакетов.

Забыл сказать по поводу переключения из одного режима в другой. Из шелла в бинарный переход по приему некоторого однобайтного NOP пакета без payload. Переход обратно в шелл по таймеру, 1 секунда например, если бинарных пакетов все ещё нет то переходим.

Для контрольной суммы будет достаточно суммы адреса конечной точки с передаваемыми данными.

Можно немного ускорить обмен если в ответе не передавать ep-number, тогда и заполнитель может оказаться не нужен. А где чей ответ и так ясно по порядку отправи запросов, если нет повреждений/пропусков байт.

На этом похоже все, достаточно просто?

Мне пока больше всего не нравиться физический уровень. Возникают сомнения о надежности работы на большой скорости (хотя бы ~400Кbit/s).
  • 0
  • 24 августа 2012, 16:37
  • amaora

Комментарии (21)

RSS свернуть / развернуть
А ем таки не угодил I2C? Он больше приспособлен для шин.
Алсо, чем не угодил девятибитный режим UART? Можно аппаратно различать адрес и команду, и свободны все 8 бит для данных.
0
  • avatar
  • Vga
  • 24 августа 2012, 16:49
9 — бит это хорошо выглядит.
тогда сервами можно будет рулить с роутера.
0
Шелл через i2c не сделаешь, так что наличие uart необходимо, им одним и хочется обойтись. А 9-ти битный режим может добавить проблем, при использовании dma, или окажется, что он где-то не поддерживается.
0
Честно говоря, я не считаю шелл чем-то нужным на серве. Конфигурить вполне можно по I2C. Пусть не напрямую через ком-порт… Но она все равно будет использоваться в связке с управляющим контроллером.
UART полезен разве что цеплять серву напрямую к нему и командовать нечто вроде cat set > /dev/ttyX.
0
Надо как-то добавить возможность делать из управляющего контроллера редиректор/прокси, в его шелее набираем connect 12 и попадаем в шелл 12-й сервы. Но как это попроще и надежнее сделать. Аппаратный мультиплексор TX/RX решил бы много проблем, но это убивает dma передачу.
0
Меня смущает наличие режимов работы и двух «протоколов» (шел и бинарный). Оно конечно может и удобно (штатный юзер интерфейс через любую терминальную программу) но как-то не аккуратненько :)

Может сделать конфигурирование через бинарный протокол (например, как в USB через нулевую конечную точку, раз у нас уже есть конечные точки).

Но это сугубо мое менение.
0
  • avatar
  • e_mc2
  • 24 августа 2012, 17:47
Упс,… наличие двух режимов работы…
0
Хотел бы я оставить один только шелл, но где столько скорости взять, чтобы протолкнуть туда управляющие команды в текстовом виде, с хорошей частотой и на несколько конечный точек.
0
Отличная невозможность простой замены в принципе, т.к. надо устанавливать номер сервы как минимум.
Замыкание линии у одной из серв кладет все сеть.
Необходимость использования уарт у мк (либо организация софтового уарта), в то время как его уарт-шелл готового устройства куда важнее, нежели шелы отдельных движков.

Это то, почему такой протоком лично мне неприемлим.
+1
Ну «plug&play» сделать можно, но я думаю не нужно. С замыканиями да, так и будет, простого/дешевого решения не вижу, у i2c та же проблема. Если uart у главного контроллера один, то да, тоже проблемка.
0
Вы ошибаетесь, если думаете что на модели можно так просто взять и заменить серву или ESC. В беольшинстве случаев ESC нужно предварительно сконфигурировать и откалибровать.

Замыкание линии у одной из серв кладет все сеть.

Эта проблема свойственна для любой сети типа «шина». Но эта топология сети успешно используется во многих «критических» областях. Например, вспомним современные промышленные контроллеры. Или современные автомобили (где все обедено в сеть от обвязки двигателя до последней лампочки и кнопочки).
0
Главное — для чего все это делается, и где эти сервы вы планируете применять.

Основное назначение и применение серв — модельная техника. Тут немаловажную роль играют традиции и совместимость. Протокол с последовательной передачей канальных импульсов разной ширины в аппаратуре пропорционального радиоуправления — появился еще в 60х годах, и окончательно утвердился в 70х. При всей своей простоте он обеспечивал достаточные параметры по точности, быстродействию, а главное — надежности и помехоустойчивости. С тех пор он стал основным стандартом для моделистов. Под него делаются как сами сервы, так и приемопередающая аппаратура. Даже с переходом на цифровые методы — протокол связи самой сервы с приемником остался неизменным. Например, сейчас популярна дешевая цифровая аппаратура на 2400 МГц. Автоматический выбор канала между приемником и передатчиком, цифровая пакетная связь между ними. Но, заметьте, в приемнике происходит преобразование цифры в тот же самый код с модуляцией длительности импульса, как и полвека назад.

Появились и «цифровые» сервы. Но, опять же, цифровые они — только внутри, от датчика положения до двигателя. Управляющий же сигнал они по прежнему получают длительностью импульса, как и аналоговые.

Почему это так? Да потому, что вы можете купить ЛЮБУЮ серву ЛЮБОГО производителя, (весом от 2-3 грамм до полкило, с усилием от долей кг до десятков кг на сантиметр), — и использовать их на любых моделях, с любой радиоаппаратурой. Не задумываясь, как и что там внутри.

Если вы делаете что-то для себя — вы можете делать что угодно, и как угодно. Это ваше право. Но если вы хотите, чтобы это применяли другие — тут возникает куча проблем с совместимостью с существующей аппаратурой.

И никакой серьезный моделист не выбросит свою надежную, проверенную годами аппаратуру, ради неизвестно чего, произведенного неизвестно кем, как бы это ни расхваливали.

Сможете ли вы обеспечить всех желающих такой же надежной, удобной, с большим функционалом, приемо — передающей аппаратурой? И кто ее возьмет, если ее будете делать только вы? Когда она сегодня есть, завтра — неизвестно…

И еще куча других подобных проблем…

Для себя же, — никто не мешает вам выкинуть из любой сервы ее плату управления, и поставить свою, управляя ей как угодно с чего угодно. Вот только — это уже будет не серва. Потому что при слове «серва» — любой моделист (и не только), знает, что это такое, как и куда ее воткнуть, и с чем угодно она будет работать.
А не неизвестно какое устройство, созданное кем — то, неизвестно зачем.

Модельная индустрия — штука жестко стандартизованная, и пробиться туда с отсебячиной — невозможно. Не примут.

Для себя же — можете делать что угодно. Хоть сразу с мобилки сервой управлять. Нет проблем, все в ваших руках. Как хотите, так и делайте.

Хотя, честно говоря, я не вижу особой выгоды, которую бы дали, например, мне в моем роботе, такие переделанные сервы. Мне гораздо удобнее использовать их родной протокол. Зная, что я в любой момент могу заменить одну серву — любой другой… Сформировать пачку импульсов с периодом 20 мс и заданной длительности, — что может быть проще для контроллера? На любых ногах порта, для любого количества серв… Уж никак не общение с ней по USART или, тем более, — I2C…

Если бы у меня использовалось большое количество серв (например, в каком-нибудь андроиде или хексаподе) — я бы и тогда предпочел не переделывать каждую серву, а поставить для управления ими выделенный контроллер, который бы через сдвиговые регистры управлял хоть полсотней стандартных серв, получая в свой очередь управление — от центрального… Это лучше, чем переделывать сами сервы.
+7
  • avatar
  • SWG
  • 24 августа 2012, 19:07
Уж никак не общение с ней по USART или, тем более, — I2C…
Ну, I2C как раз выбор пооправданней UART'а — оно есть на практически всех современных МК, легко делается в софте и изначально рассчитано на шинную топологию (хотя есть и минус — меньшая помехоустойчивость).
Сформировать пачку импульсов с периодом 20 мс и заданной длительности, — что может быть проще для контроллера? На любых ногах порта, для любого количества серв…
Ну, тут есть небольшая проблема — стабильность таймингов. У меня, например, китайская серва, управляемая ардуиновской библиотекой Servo (а она весьма неплохо сделана, надо отметить) на полную остановку не выходила — жужжала вокруг установленного положения (хотя, возможно, это проблема самой сервы — она довольно дрянненькая).

А вот во всем остальном — однозначно согласен. Да и поставить выделенный МК, который будет заниматься формированием сигнала для серв при необходимости — явно дешевле и менее избыточно, чем ставить по такому контроллеру в каждую серву.
0
У Futab-ы есть своя технология S.bus возможности которой как раз говорят о её цифровой природе. Правда, насколько я понял, и сервы требуются с поддержкой S.bus.
0
Любая цифровая серва может программироваться по тем же 3 проводам (сигнал, питание, общий), по специальному протоколу. При этом задается зона нечувствительности, максимальные углы отклонения, и куча других параметров. Для упрощения этой процедуры для неспецов (моделистов) выпускаются специальные «карты программирования» — программаторы этих параметров. Или более универсальные программаторы серв — например, www.hobbyking.com/hobbyking/store/__15515__GWS_DSP_1_Digital_Servo_Programmer.html

Сама же цифровая серва с аппаратурой общается по обычному протоколу.
Например:
www.basicmicro.com/downloads/docs/Hitec%20Digital%20Servo.pdf
www.hitecrobotics.com/Tony%20information/HMI%20Protocol.pdf

По S-Bus Гугл выдает только шину Смарт — бас для управления Умным Домом…
0
А по запросу «S-bus servo futaba» первой ссылкой выдаёт то, что нужно)
0
0
К модельной аппаратуре интерес отсутсвует так же по причине протокола, так что с совместимостью проблем не ожидается. Переделывать все сервы я никому не предлагаю. Никаких желающих ничем обеспесивать не планирую.

Наверно я слишком сильно всегда стремлюсь контролировать все компоненты системы, иначе не интересно, получается то, что все уже много раз делали, сборка из готовых модулей. И к тому же я вижу много возможностей которые которые дает этот контроль. Для примера робот манипулятор мог бы оценивать вес захваченного предмета, без дополнительных датчиков.
0
Если вы глянете по второй из приведенных мной ссылок Hitec Digital Servo.pdf, то там не только дается схема и описание их цифровых серв, но и подробно написано, что куда и как пишется в режиме программирования.
Там есть возможность просто подкдючить их к RS232 (или COM порту компьютера — через простую схему сопряжения), и не только менять параметры, но и есть команда перемещения ее в заданное положение, также — можно считать ее текущее положение, и кое-что еще. То есть, практически все, что нужно вам (разве что кроме адресации при нескольких одновременно используемых сервах).
Вот выдержки оттуда:
Serial data configuration
The serial data is at 19.2K Async 8 bits 1 stop
Getting into Serial Mode
When the servo powers up with only a light pulldown (47K) on the control input, after
about 12mS the servo sends a “+” character and pulls up the control input. You must
respond to this “+” by sending back a “+”. This has to be done within a specific time
(needs to be measured).
A couple of seconds after you send the “+”, the servo sends another “+”. You are then
in serial communication.
Serial commands are ignored unless this start-up is performed. This is one of many
locks and checks in the servo software to prevent corruption of the configuration.
Read Position Command
The read position command (e) appears to be a direct read of the ADC in the
processor from the feedback pot. I get the same result as when I read the ADC
registers from the data memory. The ADC is 10 bit, so the range of values is from 0 to
1024. The physical endpoint stops give an actual range of values of 68(0x44) to 956
(0x3BC) for my servo. So this is the best accuracy that could be achieved, though this
may be compromised by the pot.
Move Servo Command
The move servo command (f) appears to move the servo position. The range of
acceptable values on my servo seems to be 3200 (0xC80) to 8344 (0x8344). This is
strange, and I do not really understand the positioning and the relationship between
actual position, desired position, neutral and endpoints. Values outside the acceptable
range do not move the servo.
During reset the servo is calibrated moving from end stop to end stop and reading
position. Here the values of 3600 (900uSec * 4) and 8400 (2100uSec * 4) are used.
These are of course consistent with an internal timer for the PWM clocked at 4MHz.

Это предназначено, в основном, для определения и задания параметров сервы при ее программировании, но никто не мешает использовать их вам для своих целей.
0
Как человек увлекающийся моделизмом, позволю себе небольшую ремарку.

Вы все правильно написали, PWM является стандартом, и используется до сих пор, несмотря на то, что радиоаппаратура и исполнительные устройства давно уже стали цифровыми. PWM обеспечивает совместимость и это чудесно.

Но это не значит, что он полностью всех устраивает и все счастливы. Если с сервами все относительно просто, то с ESC уже появляются определенные проблемы. Например, для коптеров стандартной частоты PWM (50 Гц) мало, поэтому перешли на Fast/Turbo PWM (~400Гц). Для автомоделей, помимо оборотов двигателя нужно управлять реверсом и, желательно, режимом торможения. Приходится изворачиваться чтобы «влезть» в стандартный протокол, калибровать ESC под разные режимы.

Возможность конфигурировать сервы и ESC есть (как Вы правильно заметили). Но это расширение выглядит больше как «костыль». Для этого исполнительный механизм нужно ввести в специальный режим конфигурирования, пообщаться с сервой или ESC в «штатном» режиме не получится. А хотелось бы. Например, хотелось бы обратной связи (узнать реальное положение сервы, узнать такие параметры как ток, входное напряжение и температуру от ESC).

Шаги по переходу на цифровой обмен делаются. Про S-bus от Футабы уже вспоминали (хотя это плохой пример, т к. протокол «закрытый», и привязан к одному производителю, а vendor-lock многих отпугивает). Есть открытые проекты (автор упоминал о OpenServo, есть много других, например, ArduESC ). Для многих ESC энтузиасты выпускают альтернативные прошивки с I2C интерфейсом.

Так что не все так однозначно, и моделисты и производители уже задумаются о переходе на цифровой интерфейс. Но, пока, не все так гладко, есть много проблем (отсутствие единого стандарта и т. д).
0
Как-то так получается :-[

+1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.