Микропроцессорный передатчик и приемники
По поводу 2048бит- я думаю, это излишество. Точность передачи положения машинки достаточна, если если если количество положений вдвое больше чем разрешающая способность машинки по углу при нулевой нагрузке.
Для большинства машинок это как раз и есть 256-512 бит, в крайнем случае- 1024бит.
Исключение составляют специализированные сервы с широким диапазоном отклонения и энкодером как датчиком положения, но их в моделизме применяют редко 😃
Испытания некоторых моделей цифровых футабовских серв - показали, что ни одна из тестируемых серв не способна отработать 5us изменение канального импульса. (возможно поэтому на стандартных сервотестерах 10us шаг).
Тестировались сервы стандартного размера, но разного усилия и скорости, 4 модели. Названия моделей скажу , если надо-позже, данные на работе.
По поводу того, что точности ±6 позиций вашего закрылка вам не хватит- это только кажущиеся предположение. Во первых- большее число позиций машинка скорее всего не отработает под полетной нагрузкой, а во вторых- человек редко рулит с высокой точностью- все движения человека носят преимущественно импульсный характер.
По поводу программного вывода на машинки для AVR - если не использовать таймера вообще- то на 16Мгц можно формировать импульсы для 6 машинок за длин цикл с джиттером не более 2us (при двухбайтных значениях машинок)
Однако для этого на время вывода (2.2ms максимум) нельзя заниматься ничем другим 😃 - прерывания должны быть исключены.
Если такое время не вписывается во временную диаграмму вашего устройства- можно пойти другим путем: формировать импульсы одним таймером в последовательном коде, а на выходе поставить сдвиговый регистр или, что удобнее, счетчик Джонсона (4007, кажется).
В таком случае необходимо предусмотреть минимальное время отклика системы на прерывание от этого таймера, равное минимальному канальному импульсу+время обработки прерывания, и еще некоторый запас для работы внешнего счетчика, т.е около 700-800мкс. В самом прерывании надо будет только записать в регистр сравнения длительность соответствующего канального импульса, да еще инкрементировать счетчик канальных импульсов, т.е очень быстро.
По поводу 2048бит- я думаю, это излишество…
Для большинства машинок это как раз и есть 256-512 бит, в крайнем случае- 1024бит.
“256-512 бит…1024бит” В этих словах чувствуются знания и опыт. Спасибо, поржал, самому то не смешно?! Мы тут типа про 11.5 бита пока говорили всего, а у вас сразу 256? Согласен 256 хватит всем.
Снял ролик.
Куда видео писал? Процом на борт, передавал по каналу или просто по проводу? Можно ссылку на инфу по RT-1000? Что-то не смог найти в нете.
По поводу программного вывода на машинки для AVR - если не использовать таймера вообще- то на 16Мгц можно формировать импульсы для 6 машинок за длин цикл с джиттером не более 2us (при двухбайтных значениях машинок)
Если есть возможность запретить прерывания на 2.2ms, могу предложить метод, как имея джиттер не хуже 1/1024us и даже 1/2048us, выдавать сигнал на 8 машинок. Только обычно это не приемлемо, т.к. есть задачи требующие гораздо более высокой скорости реакции.
Так вот, будет вам известно, что у ацп любой меги всего 10 бит, причем пара младших разрядов изрядно шумят. Т.е. реально можно говорить только о 8, либо о програмном усреднении. Ну пость теже 10 бит, но это максимум 1024 бита, минус не полное использование “краев диаппазона”…
Вы говорите об интегральной или дифференциальной нелинейности? Для наших применений важна именно дифференциальная нелинейность, а она гораздо лучше указанной Вами. При желании из AVR-ных АЦП легко получают 12-битное разрешение при приемлемом самплрэйте.
Более того, вы с такой точностью стики двигать умеете? Я восхищен! Я не умею…
А я умею, при 50-80% экспонент это не большая проблема. А еще тримера умеют, и миксы. А еще есть самолеты, на которых это заметно.
“256-512 бит…1024бит” В этих словах чувствуются знания и опыт. Спасибо, поржал, самому то не смешно?! Мы тут типа про 11.5 бита пока говорили всего, а у вас сразу 256? Согласен 256 хватит всем.
Нет не смешно. Я неправильно написал, имел в виду количество положений машинки на протяжении управляющего интервала.
Возможно, мы о разных вещах говорим. Давайте введем понятие “разрешающей способности серво по управляющему сигналу”
Ставим на серву рычаг длиной 150-200мм, чтоб были заметны малые отклонения, и подключаем серву к испытательному генератору.
5us шаг изменения импульса грубо соответствует 256 позициям? то есть 8 бит. (с некоторым запасом)
2.5us - 512, то есть 9бит.
Я утверждаю, что использовать более чем 1-2us разрешение- это бессмысленно для большинства серв. 2048- это 11бит- не более чем пустое рекламное завлечение, можно и 16 и 24бита сделать, , а толку?
Если есть возможность запретить прерывания на 2.2ms, могу предложить метод, как имея джиттер не хуже 1/1024us и даже 1/2048us, выдавать сигнал на 8 машинок. Только обычно это не приемлемо, т.к. есть задачи требующие гораздо более высокой скорости реакции.
Поделитесь с общественностью, пожалуйста 😃
Вы точно не описались- менее 1ns? может, все-таки 1/1024 ms? ибо 1ns - это круто, это уже ниже чем джиттер опорного кварцевого генератора процессора:)
Я писал про обычный цикл написанный на с, практически без оптимизации, только переменные в регистрах желательно поместить- быстрее работает 😃
Тестировались сервы стандартного размера, но разного усилия и скорости, 4 модели. Названия моделей скажу , если надо-позже, данные на работе.
Serj, при возможности озвучьте названия. И, - если можно - результаты измерений. Меня давно интересуют цифры реальных характеристик брендов. Хочется сравнить с бюжетными, а также поэкспериментировать со своими контроллерами. Можно в личку.
Поделитесь с общественностью, пожалуйста…
Вы меня вполне правильно поняли, 1/1024 ms. Я тоже писал про обычный цикл на C.
serj я вас полностью поддерживаю.
Даже 256 позиций невероятно для серв обычных.
А 1024 звучит, так же как мощность колонок пластмассовых китайских за 300руб. на 300Вт.
Но на быстрых цифровых машинках - народ “на глаз” видит, что 2048 лчше чем 1024, и доводы не признают, что всякие там ПСМ2048 и т.д. - просто пиар, ибо машинки такого разрешения не дадут, а с учетом люфтов, шумов и дрожания рук - так вобще, кроме понтов ничего не остается
Если видит на глаз значит есть разница, но это может означать, что позиций стало, например, вместо 20 30 😉
Или ещё, что то улучшили, а может доработали глюки.
П.С.
Есть ещё вариант не хочется признавать, что китайские друзья развели на баблос…
Насчет быстрых машинок сказать не могу- не тестировали мы их 😃 а вот насчет S3151, S3152 S3050 и аналоговая S3003- 5 микросекунд разрешения без нагрузки дают.
На работе весь инет съели 😦, пишу из дома, что запомнил:
При тесте- питание 5 вольт, 4-амперный преобразователь.
У более мощных S3050 и S3152 (5кг/см, 200ms/60град) - разрешающая способность без нагрузки такая же, и не растет, как ни странно по сравнению с S3151(3кг/см, 200ms/60град)- но под нагрузкой они ведут себя не в пример лучше- сдвиг на тот же угол обеспечивается при втрое почти большей нагрузке чем у 3051, и составляет около килограмма/см,т.е 20% заявленного полного усилия, что неплохо 😃
Самая слабая - это аналоговая 3003- ей надо 200г приложить чтобы она не дергалась от 5us.
Точность положения от нагрузки не измерялась, т.к. в нашем приложении она выбирается интеграторами…
Но на быстрых цифровых машинках - народ “на глаз” видит, что 2048 лчше чем 1024, и доводы не признают, что всякие там ПСМ2048 и т.д. - просто пиар, ибо машинки такого разрешения не дадут, а с учетом люфтов, шумов и дрожания рук - так вобще, кроме понтов ничего не остается
Возможно, “на глаз” они видят разную задержку, а не разрешающую способность- отсюда и критерий- что на 2048 летать четче …
Голубев вот говорил, что он на спектруме нормально летает, а на футабе- хуже- задержки не стабильные. в это вериться намного больше чем в способность отличить 2048 позиций от 1024 😃
Куда видео писал? Процом на борт, передавал по каналу или просто по проводу? Можно ссылку на инфу по RT-1000? Что-то не смог найти в нете.
Отвечу за автора 😃 Он передавал видео с борта на комп по радио каналу. Отсюда и помеха наверно. Но ничо, отладится
Пару слов о потоковом видео.
Есть опенсорс проект в котором реализовано сжатие опенсорсным Theora на ПЛИСке. Пытался поиграть с параметрами кодека чтобы вписаться в узкий канал при удовлетворительном качестве. Не знаю пока тонкостей работы Theora. Может ли сильно скакать там битрейт или настраивается постоянный (а может если и изменяется, то не сильно). В общем больше вопросов чем ответов.
Некоторые идеи в теме на http://www.VRTP.ru написал, цифры, тестовые кадры сжатые на компе выложил…
На данный момент хочу просто подключить камеру и научиться жать поток в реальном времени. Думаю производительности ПЛИСки хватит чтобы сжимать поток с минимальным битрейтом для передачи по каналу и в нормальном качестве для записи на карту памяти.
Также натыкался на реализацию H.264. С ним качество вроде получше должно быть. Пока не тестил.
Надеюсь мои попытки приведут хоть к какому-нибудь результату и появится полезные наработки. На данный момент ничего толкового нет.
PS: Спасибо за внимание!
Usr1, Вы делаете опенсорс проект? или закрытый?
Пару слов о потоковом видео.
Не видел Theora, на чем написано, System C ?
Какой смысл делать задачу хорошо отработанную в DSP железе на плисине? Дипломный проект? Сравнивал в схожей задаче потребление, FPGA Spartan 3A уступал DSP TMS320DM6437, в итоге склонился к варианту на последнем.
Пару слов о потоковом видео.
Usr1, Вы делаете опенсорс проект? или закрытый?
Скажу честно - пока не решил. Проект однозначно не будет чисто коммерческим, но и об опенсорсности пока не думал. Сначала хочется получить хоть какой-то драфтовый вариант. К сожалению, личные обстоятельства отрвали меня от проекта больше, чем на месяц. Да еще и P51 необлетанный, неошлифованый и неокрашеный на шкафу лежит 😃