Микропроцессорный передатчик и приемники
… но и загнать в приемлемые рамки - задача не простая. Если конечно процессор ни чем другим не занимается…
ПЛИ-СИ-НА, ПЛИ-СИ-НА😆
У меня ничем не занимается 😃
Именно.
Если конечно процессор ни чем другим не занимается…
Угу. Именно так. Единственное приемлимое решение это заниматься процессору только этим. Поэтому я сразу и сориентировался на встроеный контроллер и внешнее мультиплексирование. Все таки дергать чипселект и перепускать ШИМ раз в пять милисекунд гораздо менее затратно для проца. И джиттера быть не должно. будет только смещение передних фронтов каждой четверки относительно друг друга в течение 20 мс.
Ясно. Спасибо всем. Я действительно поспешил, не проработав аналоговую часть.
А давайте я вам предложу лучшее место для приложения сил и знаний?
Вот рулевые машинки управляются длительностью импульса, и из-за использования схемотехники одновибраторов сильно подвержены воздействию помех как по питанию, так и по наведению на сигнальный провод.
Однако и приемник (кроме РРМ) и цифровая сервомашинка уже имеют в себе цифровую часть - надо сделать передачу данных приемник-машинка в цифровом виде!
А давайте я вам предложу лучшее место для приложения сил и знаний?
Вот рулевые машинки управляются длительностью импульса, и из-за использования схемотехники одновибраторов сильно подвержены воздействию помех как по питанию, так и по наведению на сигнальный провод.
Однако и приемник (кроме РРМ) и цифровая сервомашинка уже имеют в себе цифровую часть - надо сделать передачу данных приемник-машинка в цифровом виде!
А разве openservo недостаточно? Там команды на сервы поступают по I2C.
А разве openservo недостаточно? Там команды на сервы поступают по I2C.
Кто генерит команды?
Нужен ведь РС-приемник…
надо сделать передачу данных приемник-машинка в цифровом виде!
Сделать то все можно…, только нужно-ли? При управляющем ШИМе цепляй любую серву и в путь!, … а при передаче управляющего кода - еще и с сервами шаманить… 😃 … ну и соответственно свой регуль на електричку клепать …
Сделать то все можно…, только нужно-ли? При управляющем ШИМе цепляй любую серву и в путь!, … а при передаче управляющего кода - еще и с сервами шаманить… 😃 … ну и соответственно свой регуль на електричку клепать …
С появлением аппаратуры на 2.4ГГц фактически пропали помехи из эфира. Остались и обострились помехи на самом борту…
Да, если уж переходить на новый протокол передачи данных приемник-исполнительный механизм, то надо менять и машинки (электронику) и регули…
И когда-то это произойдет (если еще раньше в каждой РМ не поселится по одноканальному приемнику, “подшиваемому” на нужный канал передатчика…
если уж переходить на новый протокол передачи данных приемник-исполнительный механизм, то надо менять и машинки (электронику) и регули…
Все надо… 😃 Но не так быстро… 😃
Остались и обострились помехи на самом борту…
Помехи на борту не обострились… Просто надо грамотно монтировать борт и проблем не будет… 😃 На сервы и так сигнал идет в виде логических уровней по амплитуде и если там есть помехи - то все вопросы к правильной разводке, а вот дрожание фронта в ШИМ - это уже вопрос схемотехники и реализации…
Для передачи сигналов на такие расстояния в рамках реальных рабочих точностей отработки вовсе не надо уходить на передачу кода…
Все надо… 😃 Но не так быстро… 😃
Все более нужное дело, чем новый передатчик-приемник…
Помехи на борту не обострились… Просто надо грамотно монтировать борт и проблем не будет… 😃 На сервы и так сигнал идет в виде логических уровней по амплитуде и если там есть помехи - то все вопросы к правильной разводке, а вот дрожание фронта в ШИМ - это уже вопрос схемотехники и реализации…
Для передачи сигналов на такие расстояния в рамках реальных рабочих точностей отработки вовсе не надо уходить на передачу кода…
От логического уровня сигнала на сервы никому ни холодно ни жарко - он не используется ни как. Работают фронты, что для цифровой техники позапрошлый век.
“Такие расстояния” - это около метра, а то и больше. Рядом с силовыми проводами а-ля электросварка и точно с такими же фронтами токов…
А разве openservo недостаточно? Там команды на сервы поступают по I2C.
Классный проект! Надо взять на заметку. Как-нибудь попробую прикрутить…
Кто генерит команды?
Нужен ведь РС-приемник…
МК, ну их проект можно взять за основу, он вроде как отлажен
МК, ну их проект можно взять за основу, он вроде как отлажен
Главное чтобы у них API был достаточно отлажен…
Работают фронты, что для цифровой техники позапрошлый век. “Такие расстояния” - это около метра, а то и больше. Рядом с силовыми проводами а-ля электросварка и точно с такими же фронтами токов…
Переходите на оптоволокно… 😃
Переходите на оптоволокно…
Согласованной дифференциальной линии будет достаточно.
Исключить полностью возможно (даже без аппаратного ШИМ), если прогу аккуратненько написать. А приемлемые для сервы рамки - это сколько мкс в цифрах ?
Исключить его полностью, в такой реализации почти невозможно, но и загнать в приемлемые рамки - задача не простая.
Исключить полностью возможно (даже без аппаратного ШИМ), если прогу аккуратненько написать. А приемлемые для сервы рамки - это сколько мкс в цифрах ?
Современная аппаратура имеет разрешение 11 бит, что соответствует примерно 500 наносекунд, джитер хочется иметь хотябы вдвое меньше разрешения, иначе нахера оно нужно… Даже при использовании вложенных прерываний обеспечить такой джитер будет ооооочень сложно, если у вас есть потребности обрабатывать и другие прерывания.
ATMEGA88 например на 20 МГц справится, 1 команда выполняется 50 нс. За 5 команд в принципе можно успеть свалить из другого более низкоприоритетного прерывания и выставить ноги управления сервами. Другое дело что для нескольких каналов все равно появится задержка, то есть каналы НЕ одновременно будут изменяться. ПЛИС конечно справится с такой задачей гораздо лучше. Даже не предполагал что такая проблема сделать хороший многоканальный кодер или декодер. Спасибо за разъяснения.
что соответствует примерно 500 наносекунд, джитер хочется иметь хотябы вдвое меньше разрешения
А разве openservo недостаточно? Там команды на сервы поступают по I2C.
+1, да и у Конзе есть прошивка к китайским регулям (копиям джети 18) с управлением по и2с. Правда Конзе не из-за помехозащищенности вроде, а ради быстродействия для ХУФО новый борт изобретал… Но всеравно, принципиально новая цифровая электронника уже полным комплектом!
В принципе можно многое, я в свое время поприседал когда делал декодер PCM1024 на восьмой меге. Гораздо лучше делать это аппаратно. И еще неплохо бы высталять данные в каналы одновременно, т.к. если машинки должны работать синхронно (например половинки РВ), то не гоже делать меж ними задержку…
Кстати, в АВР нет ведь управления приоритетами прерываний?
Тут надо определиться: Вам ехать или шашечки, ну в смысле разрабатывать аппаратуру или летать ? Если летать и оттачивать свое мастерство как пилота то лучше взять готовое, проверенное не одной тысячой любителей этого дела и профи. Если разрабатывать аппаратуру, то как говорится в добрый путь.
В принципе можно многое…
Явного нет, но можно сделать. При входе в низкоприоритетное прерывание выставить флаг разрешения прерываний. Тогда при приходе высокоприоритетного, контроллер уйдет на него. Естественно при этом не забыть сохранить статус и другие нужные регистры.
Кстати, в АВР нет ведь управления приоритетами прерываний?