Что же такое S.Bus и какова ее эффективность? Где и как ее можно применить?
1. Решение крайне полезное для больших и дорогих моделей.
2. Неоправданное удорожание оборудования. Возможность использования только фирменного оборудования Futaba.
И еще не известно, чем бы все кончилось, но как всегда подсуетились китайцы. На рынке появились дешевые приемники с выходом S.Bus и специальные декодеры, позволяющие подключать к шине обычные сервоприводы. А совсем недавно появился совсем уж невозможный в мире гигантов рынка продукт. Orange выпустила линейку приемников, работающих в стандарте DSM2(Horizon Hobbies USA) и имеющих в числе прочего выход S.Bus.
Давайте все же посмотрим повнимательнее на это изобретение и определимся, чем же оно может быть полезно рядовому моделисту. S.Bus – это не что иное как протокол передачи команд сервоприводам по цифровому последовательному порту. Протокол этот является закрытым и Futaba его описание ни где не публиковала. Однако некоторое время назад я смог найти его описание на одном из зарубежных сайтов. Вот что мне удалось установить:
1. Протокол позволяет передавать информацию о 16-и пропорциональных каналах с разрешением 11бит на каждый и двух цифровых каналах (1 бит на канал).
2. Протокол передает информацию об ошибке пакета (Frame lost) и активации режима failsafe.
3. Скорость последовательного порта нестандартная – 100000 бод.
4. Длинна одного пакета 25 байт
5. Передача пакета происходит каждые 14мс для аналогового режима или каждые 7мс для цифрового.
Пакет данных устроен следующим образом:
[startbyte] [data1] [data2] .... [data16] [flags][endbyte]
[startbyte] = 0xF0
[dataX] = 11 бит информации канала X, которые задают ширину импульса ШИМ в микросекундах.
[flags] = 8 бит, каждый из которых имеет следующее назначение:
7 – цифровой канал 2
6 – цифровой канал 1
5 – Frame lost
4 – включен режим failsafe
3 – не используется
2 – не используется
1 – не используется
0 – не используется
[endbyte] = 0x00
Надо так же иметь ввиду, что сигналы шины, как во всех продуктах Futaba, инвертированы.
Область применения.
Если Вы обладаете моделью самолета с размахом крыла 1.5м и управляющейся по 5-ти каналам без использования каких-либо систем стабилизации сложнее RX3S OrangeRX, то Вы скажете «а зачем козе баян» и будете правы. В таких случаях нет смысла усложнять оборудование. Никаких выигрышей оно явно не несет. У Вас большая модель? Тут каждый решает сам. Ведь обходились же как-то без этого раньше. А оправданы ли доп. Вложения или нет – каждый решит сам.
На мой взгляд, самые интересные перспективы открываются для людей, которые занимаются строительством моделей с программируемым микроконтроллером на борту.
В общем случае возможны 2 варианта подключения к приемнику:
1. Использование обычного приемника с подключением микроконтроллера к каждому каналу. Данный вариант самый расточительный с точки зрения использования ресурсов микроконтроллера. Во-первых, надо задействовать столько выводов микроконтроллера, сколько каналов приемника мы хотим использовать. Для определения ширины импульсов надо задействовать таймер. При измерении ширины импульса же неизбежно возникает погрешность.
2. Использование приемника с выходом PPM. Отличие этого варианта от первого в том, что все каналы передаются последовательно друг за другом по одному проводу. Это позволяет экономить выводы и прерывания микроконтроллера. Остальные же проблемы сохраняются – надо использовать таймер и рассчитывать ширину импульса для каждого канала.
Что может дать нам использование S.Bus?
1. Использование обычного хардварного последовательного порта позволяет отказаться от прерываний. Теперь микроконтроллер будет принимать данные без использования ресурсов ядра.
2. Несколько несложных побитовых операций над 25-ю байтами позволяют получить точные данные сразу о 16-ти каналах. Если быть сосем точным, то о 16-ти пропорциональных, двух цифровых и о активации приемником режима failsafe. При этом нам не нужен таймер для вычисления времени. В пакете передаются уже готовые числа. Это же позволяет избежать погрешности: мы получим ровно те числа, которые передал приемник.
Теперь о минусах:
1. Нам нужен приемник с поддержкой S.Bus. В стандарте FASST(Futaba) можно использовать например FrSky TFR4, для аппаратуры - DSM2 можно использовать приемник OrangeRx R710.
2. Между приемником и микроконтроллером придется поставить инвертор. Для этих целей подойдет микросхема 74HC14. Она содержит сразу 6 необходимых нам элементов. 50 рублей, маленькая макетка и пять минут пайки.
Это что касается приема сигнала. А как обстоит дело с управлением сервоприводами? Опять рассмотрим типовую ситуацию:
ATmega 328 имеет всего 6 выводов, на которых можно генерировать ШИМ аппаратным путем. Стоит так же сказать, что при этом накладывается ряд ограничений на использование таймеров и прерываний. Можно генерировать ШИМ и программным путем, но для этого нам потребуются таймер и вычислительные ресурсы ядра. Ну и конечно же нам понадобится по одному выводу микроконтроллера на каждый канал управления (серву, ESC и пр.). На мой взгляд, это просто расточительство.
Чем же тут может быть полезен S.Bus? Ответ очевиден: вместо всего описанного выше нам понадобится все тот же аппаратный последовательный порт, все тот же инвертор и… несколько строчек кода для формирования байтового массива. Но родные сервоприводы Futaba использовать достаточно дорого. И в этом случае нам снова помогут предприимчивые китайцы. SBD4 S.BUS декодер за 500р. позволит нам подключить четыре обычные сервы или ESC к шине S.Bus. Есть также комплект с картой программирования. Увы, чтоб использовать все 16 каналов нам понадобится либо еще 3 последовательных порта микроконтроллера, либо хаб Futaba S.Bus Terminal Box 4-Way. Последнее предпочтительнее ввиду того, что на взятом для примера микроконтроллере всего один последовательный порт, а ATmega 2560 с четырьмя портами уже дороже и гораздо сложнее в распайке. Она уже не выпускается в удобном для сборки «на коленках» DIP корпусе. Хотя тут уже все зависит от конкретного места применения и используемых аппаратных средств.
Итого: В случае использования с микроконтроллерами S.Bus позволяет полностью избавиться от работы с ШИМ, переложив это на аппаратную часть. Как следствие – упрощение кода, уменьшение загрузки микроконтроллера и увеличение быстродействия.
Полезные ссылки:
http://www.futaba-rc.com/sbus/index.html
http://mbed.org/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/
http://arduino.cc/forum/index.php/topic,99708.0.html
http://github.com/mikeshub/FUTABA_SBUS
Лично меня эта тема заинтересовала как альтернатива съему PPM с приемника FrSky для варианта использования приемника OrangeRx R710. А то как-то спектрумовская аппа без дела пылится... :)
Эту систему уже давно используют в робототехнике для последовательного соединения сервоприводов. Вот пример http://robosavvy.com/store/product_info.php/products_id/554?osCsid=aa83cdedbc0a8ac2a9406d6c1c06c149
http://www.robotmarketplace.com/products/KT-KTXGLADIATOR.html
Как на счет СВП с многосекционной юбкой и системой контроля давления в ней(и под ней)?
2 канала управления ходовыми двигателями
2 канала рулевых
2-4 канала - нагнетатели в юбку
4-6 шторок (по серве на каждую) распределения давления внутри юбки на каждую сторону.
Итого: 14 каналов.
А еще хочется и баловства: свет + пиротехника :)
Хочу заметить: строится не "паркетник". По задумке модель должна сама различать тип поверхности под ней (паркет/вода/камни/песок и т.д.), учитывать тип маневра (спуск/подъем/поворот/ход/удержание) и выдавать сигналы управления в каналы.
Экраноплан так и завис на стадии чертежей и математики после того как я приятелю проболтался.
ЦАГИ у меня тоже под рукой нет. Все делаю медленно, со своими "граблями" и "велосипедами"....
А вот начинка часто не самая простая...
Идея была такой: Берем CPPM и разбираем его на МК. Берем инфу с датчиков и рассчитываем режим модели. Делаем соответствующие "танцы с бубнами" над массивом каналов.
А вот само управление каналами отдаем специальному контроллеру (Pololu Mini Maestro).
Если ног у МК не хватает, то один такой доп контроллер может предоставить до 12 аналоговых или 24 цифровых входа.
Я рассчитываю, что S.Bus мне поможет избавиться от CPPM.
А вообще, на вкус и цвет все фламастеры разные.
Я этим вопросом занялся поскольку указанный в статье декодер оказался у меня в руках и лежал без толку.
Цель самой статьи - предоставить описание протокола и его возможные применения.
Мое личное мнение - все преобразования должны быть аппаратными. Программируемой должна быть только логика.
Применимо скажем так в робототехнике и сложных манипуляторах где сервомеханники реально много ... на там давно уже используються цифровые шины на подобе i2c
ATmegaX8 (48, 88, 168, 328) может генерировать 16 стандартных ШИМ-сигналов без серьёзных ограничений на таймерах: 16-битный таймер должен быть "сквозным", без CTC, и занимаются оба Output Compare модуля на нём. При этом тот же таймер можно одновременно использовать для захвата CPPM и для измерения рабочих интервалов в программе. Ножек АТмеги понадобится всего 4 штуки, и ещё понадобятся две микросхемы сдвиговых регистров с последовательным вводом. Точность такого ШИМ 12 бит, нагрузка на ядро минимальна, проверено.
Так что для самодельщиков ценность S-Bus только в уменьшении количества проводов.
1. Сам по себе захват CPPM кушает достаточно ресурсов. Обработка внешнего прерывания 2 раза на каждые 1000 - 2000мкс при 16МГц тактовых заберет у ядра примерно 10-15%.
2. см даташит ATmega 328 - 6 аппаратных шим. При этом делитель и сброс таймеров должны быть богоданными. Программно шим я могу сделать на любой ее ноге. Но это опять же ресурс ядра... Сдвиговые регистры - штука хорошая, но не самостоятельная. Это не аппаратный генератор...
3. Точность не только в битности. Достаточно подключить к 328 атмеге осциллограф чтоб понять каковы биты на самом деле... Сигнал плавает до 2-4 мкс!
Тут же речь о том, что МК занимается только датчиками и математикой. Все преобразования ШИМ(туда-обратно) - аппаратные.
Мне же самому пока сервоконтроллеры Pololu больше нравятся(генерация ШИМ с точностью до четверти мкс). Данная тема пока скорее как эксперимент. Вот если эксперименты покажут высокую точность при минимуме финансовых и аппаратных затрат - можно будет применять...
А в голом виде(как ее Futaba преподносит), мне кажется, технология не имеет смысла.
В случае настолько сложных вычислений, что мега уже не может использовать прерывания, никто не мешает вместо S.Bus поставить отдельную АТмегу - будет намного дешевле. Мега48 стоит 50 рублей, отдельный кварц для неё ещё рублей 15, два сдвиговых регистра ещё 40 рублей. И она возьмёт на себя полностью ввод/вывод ШИМ (а при желании ещё и миксеры), а общаться с основной мегой сможет по SPI, ножки которого всё равно обычно заняты на разъём программирования.
Словом, если придётся что-то паять и самодельничать, то лишняя мега будет предпочтительнее покупки S.Bus. Для "серьёзных моделистов" S.Bus полезен как готовый системный продукт с гарантией производителя и отсутствием необходимости прикладывать руки.
Насчёт 15% ресурсов на захват ШИМ: при 20МГц прерывание будет выполняться каждые 50К тактов. Вход-выход из прерываний у меги мгновенные - это её основная "фишка". В процедуре прерывания всего 36 инструкций. Так что можно считать, что она занимает менее 0.1% процессорного времени.
А про "не доверять встроенному генератору" можно по-подробнее?
Вот код прерывания вывода ШИМ пожирнее, но всё равно они даже вместе много не съедят.
Главное то, что эти прерывания не обязаны выполняться в точные моменты времени - ведь фронт считывается и генерируется полностью аппаратно, а прерывания нужны только для подготовки к следующему фронту.
Встроенный генератор (или осциллятор, не помню уже точно), который 8 МГц, плавает по частоте довольно заметно, поэтому надо использовать внешний.
100% маркетинг.
Так же в заголовок статьи стоит добавитm что-то типа Futaba S.Bus - делаем сами!
С некоторых пор меня заинтересовала тема отказа от CPPM. Пока рассматриваю варианты, делаю тесты... Про DSM2/DSMX писать не стал, т.к. тут и без меня информации навалом. Хочу еще попробовать OpenLRS докрутить. Тема сулит хорошие перспективы т.к. возможно получится использовать вообще готовую железку и забыть про PPM заодно и в передатчике. 700р за цифру на каждую сторону - просто мечта! Осталось понять где подвох.
RF-модуль на аппаратном SPI, атмега328 вообще "непонятно чем занимается"... В передатчике вообще жесть: одна мега генерит PPM, другая тут же его разбирает... Зачем?
Универсальность ВЧ-модуля? - ну дык у меня же не серийное производство и от пульта мне давно уже нужен только корпус со стиками...