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

rc-серво-протоколу
Поки лише деякі думки про те, яким повинен бути протокол та інтерфейс до сервів та інших контролерів двигунів. Пишу щоб послухати критику, пропозиції щодо покращення.

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

Другий режим – це бінарний протокол для управління мережею slave пристроїв. Схема підключення наступна на прикладі трьох пристроїв.

заміна

Діоди і підтяг ставляться поруч із RX, отже через резистор відбувається заряд лише ємності діодів а чи не всіх проводів.

Що буде в payload визначається номером кінцевої точки. Тобто якщо ми щось кудись посилаємо, треба знати який там пристрій і що він приймає. Для серви можна так.

У S можна покласти контрольну суму, можна нічого.

Номер кінцевої точки визначає не тільки формат пакета, але й наявність/відсутність відповіді. Сам процес відповіді виглядає так.

Як можна здогадатися, цей протокол пристосований для використання DMA. Формуємо масив з усіма пакетами та включаємо передачу. По закінченню маємо прийнятий масив пакетів у відповідь.

Забув сказати про перемикання з одного режиму в інший. З шелла в бінарний перехід по прийому деякого однобайтного пакета NOP без payload. Перехід назад в шелл по таймеру, 1 секунда наприклад, якщо бінарних пакетів все ще немає, то переходимо.

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

На цьому схоже все досить просто?

Мені поки що найбільше не подобається фізичний рівень. Виникаютьсумніви про надійність роботи на великій швидкості (хоча б

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

Мене бентежить наявність режимів роботи та двох «протоколів» (ішов і бінарний). Воно звичайно може і зручно (штатний користувач інтерфейс через будь-яку термінальну програму) але якось не акуратно :)

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

Але це суто моя зміна.

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

Це те, чому така протока особисто мені неприйнятна.

Ви помиляєтеся, якщо думаєте, що на моделі можна так просто взяти і замінити серву або ESC. У більшості випадків ESC необхідно попередньо налаштувати і відкалібрувати.

Замикання лінії біля однієї з серв кладе всю мережу.

Головне – для чого все це робиться, і де ці серви ви плануєте застосовувати.

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

З'явилися й «цифрові» серви. Але, знову ж таки, цифрові вони лише всередині, від датчика положення до двигуна. Керуючий сигнал вони як і отримують тривалістю імпульсу, як і аналогові.

Чому це так? Та тому, що ви можете купити БУДЬ-ЯКУ серву БУДЬ-ЯКОГО виробника, (вагою від 2-3 грам до півкіло, з зусиллям від часток кг до десятків кг на сантиметр), - і використовувати їх на будь-яких моделях, з будь-якою радіоапаратурою. Не замислюючись, як і що там усередині.

Якщо ви робите щось для себе - ви можете робити будь-що, і як завгодно. Це ваше право. Але якщо ви хочете, щоб це застосовували інші, тут виникає купа проблем із сумісністю з існуючою апаратурою.

І ніякий серйозний моделіст не викине свою надійну, перевірену роками апаратуру, заради невідомо чого, зробленого невідомо ким, хоч би як це розхвалювали.

Чи зможете ви забезпечити всіх бажаючих такою ж надійною, зручною, з великим функціоналом, приймально-передавальною апаратурою? І хто її візьме, якщо її робитимете тільки ви? Коли вона сьогодні є, завтра невідомо.

І ще купа інших подібних проблем.

Для себе ж, ніхто не заважає вам викинути з будь-якої серви її плату управління, і поставити свою, керуючи їй як завгодно з чого завгодно. Ось тільки це вже буде не серва. Тому що при слові «серва» — будь-який модельіст (і не тільки), знає, що це таке, як і куди її встромити, і з чим завгодновона працюватиме. А не невідомо який пристрій, створений кимось, невідомо навіщо.

Модельна індустрія – штука жорстко стандартизована, і пробитися туди з відсеб'ячиною – неможливо. Чи не приймуть.

Для себе ж можете робити що завгодно. Хоч одразу з мобілки сервою керувати. Нема проблем, все у ваших руках. Як бажаєте, так і робіть.

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

Якби я використовувала велику кількість серв (наприклад, в якомусь андроїді чи хексаподі) — я б і тоді вважав за краще не переробляти кожну серву, а поставити для управління ними виділений контролер, який би через зсувні регістри керував хоч півсотнею стандартних серв, отримуючи У свою чергу управління - від центрального ... Це краще, ніж переробляти самі серви.

Аж ніяк не спілкування з нею по USART або, тим більше, I2C ...

Сформувати пачку імпульсів з періодом 20 мс та заданої тривалості, що може бути простіше для контролера? На будь-яких ногах порту, для будь-якої кількості серв.

Ну тут є невелика проблема — стабільність таймінгів. У мене, наприклад, китайська серва, керована ардуїновською бібліотекою Servo (а вона дуже непогано зроблена, треба відзначити) на повну зупинку не виходила — дзижчала навколо встановленого становища (хоча, можливо, це проблема самої серви — вона досить погана).

А оту всьому іншому - однозначно згоден. Та й поставити виділений МК, який займатиметься формуванням сигналу для серв за потреби, — явно дешевше і менш надмірно, ніж ставити за таким контролером у кожну серву.

Будь-яка цифрова серва може програмуватися за тими ж трьома проводами (сигнал, харчування, загальний), за спеціальним протоколом. При цьому визначається зона нечутливості, максимальні кути відхилення, і купа інших параметрів. Для спрощення цієї процедури для неспец (моделістів) випускаються спеціальні «карти програмування» - програматори цих параметрів. Або більш універсальні програматори серв — наприклад, www.hobbyking.com/hobbyking/store/__15515__GWS_DSP_1_Digital_Servo_Programmer.html

До модельної апаратури інтерес відсутній також через протокол, так що із сумісністю проблем не очікується. Переробляти всі серви я нікому не пропоную. Жодних бажаючих нічим забезпечувати не планую.

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

Це призначено, в основному, для визначення та завдання параметрів серви при її програмуванні, але ніхто не заважає використовувати їх для своїх цілей.

Як людина, що захоплюється моделізмом, дозволю собі невелику ремарку.

Ви все правильно написали, PWM є стандартом, і використовується досі, незважаючи на те, що радіоапаратура та виконавчі пристрої давно вже стали цифровими. PWM забезпечує сумісність і це чудово.

Але це не означає,що він повністю всіх влаштовує та всі щасливі. Якщо з сервами все досить просто, то з ESC вже виникають певні проблеми. Наприклад, для коптерів стандартної частоти PWM (50 Гц) мало, тому перейшли на Fast/Turbo PWM (

400Гц). Для автомоделей, крім обертів двигуна, потрібно керувати реверсом і, бажано, режимом гальмування. Доводиться вивертатися, щоб «влізти» в стандартний протокол, калібрувати ESC під різні режими.

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

Так що не все так однозначно, і моделісти та виробники вже замисляться про перехід на цифровий інтерфейс. Але, поки що, не все так гладко, є багато проблем (відсутність єдиного стандарту тощо).