Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Угловой энкодер: устройство и процедуры обработки данных  (Прочитано 3991 раз)
0 Пользователей и 1 Гость смотрят эту тему.
stoctman
Читатель

az
Offline Offline

« : 05-03-2015 10:26 » 

Всем доброго времени

У меня возник вопрос по теме https://club.shelek.ru/viewart.php?id=369#post_A5
Если отбросить изготовление ДУП и применить существующую современную базу
магниторезистивных ДУП или инкрементных энкодеров как ДУП
какой на ваш взгляд способ измерения угла будет более точным и быстрым
используя один и тотже контроллер на борту которого имеется как SPI интерфейс так и 2х16 битных счетчика?
экономические параметры не в щёт магниторезисторные сенсоры типа
http://www.infineon.com/dgdl/Infineon-TLE5011-DS-v02_00-en.pdf?fileId=db3a30432ee77f32012f0c4368b5110e
гораздо дешевле оптических програмируемых инкрементных энкодеров типа
http://www.lika.it/eng/file7.php?id_file=3082

благодарю за ответ
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 05-03-2015 11:08 » 

какой на ваш взгляд способ измерения угла будет более точным и быстрым

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

TLE5011, судя по данным производителя, нуждается в периодической калибровке и в постоянной температурной компенсации показаний. Плюс при обработке показаний необходимо использовать тригонометрические функции sin, cos, arctan. Конечно, для ПК или продвинутого контроллера с процессором плавающей арифметики это не проблема, а вот 8-битные карлики наподобие AVR или PIC не сильны в этом. Даже после этих усилий, согласно табл. 10, ошибка может достигать 2.2 градуса. Да и не совсем понятно, как он будет вести себя в промышленных условиях при наличии посторонних магнитных полей (полагаю, не очень хорошо).

Оптические энкодеры более предсказуемы на этот счет: точность стабильна и не хуже размера риски на лимбе. Чтобы исказить эти данные, нужно запачкать либо лимб, либо оптопару.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
stoctman
Читатель

az
Offline Offline

« Ответ #2 : 05-03-2015 11:53 » 

Большое спасибо за ответ!
Промышленных условий правда нет, предполагается что это будет реально высокоточный джойстик на совремменных оптических энкодерах
с числом импульсов на оборт вплоть до 65535, правда пока заоблочной цены.
я предполагаю что такой датчик http://www.nxp.com/documents/data_sheet/KMZ41.pdf без встоенного АЦП
но с использованием всё тех же 8bit AVR или PIC будет ещё хуже?

Многие ставят под вопрос целесообразность, но задача состоит не в этом.
Если поставить приоритет на точность и быстродействие то факт что энкодер будет и точнее и быстрее невызывает же сомнения?
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 05-03-2015 12:34 » 

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

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

Вообще какие требования к точности и скорости предъявляет предметная область применения джойстика?

но с использованием всё тех же 8bit AVR или PIC будет ещё хуже?

Помимо того, что вычисление трансцедентных функций на 8-битном контроллере само по себе не слишком быстрая затея, так еще и скажется невысокая разрядность встроенных АЦП (например, для AVR типично 10 бит). Все-таки в TLE5011 встроенный АЦП имеет разрешение на полтора порядка выше.

факт что энкодер будет и точнее и быстрее невызывает же сомнения?

Смотря сколько рисок у него на лимбе. Хороший энкодер - да, наверняка окажется быстрее и точнее.

Только учтите еще, что при использовании инкрементального энкодера нужно будет как-то установить начальную точку отсчета. Для магнитного датчика это не нужно.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
stoctman
Читатель

az
Offline Offline

« Ответ #4 : 05-03-2015 14:16 » 

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

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

Вообще какие требования к точности и скорости предъявляет предметная область применения джойстика?

про скорость вы наверно неправельно поняли, я имел в виду скорость доставки показаний от сенсора к экрану монитора
многие предпочитают пренебрегать временем АЦП преобразования, для некоторых 8бит AVR это к примеру 13 тактов в частности,
мелкие задержки имеют иногда свойство наращиваться в большие, тут я неуверен по поводу эффекта от них но однозначно что
от счетчика данные дойдут быстрей чем от АЦП?

ну требования очень широкие комуто достаточно и обычных резисторов
комуто недостаточно даже магниторезисторов, в прочем для того чтоб убедится в том что действительно недостаточно
надо сначала возпользоватся джойстиком на чём то другом в частности на энкодерах, мне посчастсливилось воспользоваться таким устройством на образцовом стенде медицинского хирургического комплекса, но большенству это недоступно вот и немогут поверить в разницу между землёй и небом.
Но то что целесообразно для медицины то почемуто по мнению многих неможет быть целесообразно для компютерных игр, всевозможных компютерных симуляторов
управления различной техникой, в том числе IOC (интелектуальное кресло оператора) на современных буровых платформах.


Помимо того, что вычисление трансцедентных функций на 8-битном контроллере само по себе не слишком быстрая затея, так еще и скажется невысокая разрядность встроенных АЦП (например, для AVR типично 10 бит). Все-таки в TLE5011 встроенный АЦП имеет разрешение на полтора порядка выше.

И наверно время исполнения АЦП цикла меньше?

Смотря сколько рисок у него на лимбе. Хороший энкодер - да, наверняка окажется быстрее и точнее.
Только учтите еще, что при использовании инкрементального энкодера нужно будет как-то установить начальную точку отсчета. Для магнитного датчика это не нужно.
Если вы видели пдф на энкодер в начале поста там сказано что рисок у них может быть аж до 65535
это 0.0055 физических градуса!!! Улыбаюсь
начальная точка это очень легко  две оптопары по осям в нужном месте и их опрос по прерыванию.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 05-03-2015 15:04 » 

про скорость вы наверно неправельно поняли, я имел в виду скорость доставки показаний от сенсора к экрану монитора

Точно, я скорость трактовал как скорость именно реакции датчика на движение руки. Если речь о задержках передачи данных, то они по человеческим меркам будут совершенно незначительны и будут определяться скорее скоростью интерфейса.

однозначно что от счетчика данные дойдут быстрей чем от АЦП?

Пожалуй, да. Хотя,если Вы замените микроконтроллер, допустим, на ARM Cortex-M, то его встроенный АЦП дает до миллиона выборок в секунду. Не думаю, что за микросекунду человеческая рука успеет значительно сместиться, поэтому временем преобразования действительно можно будет пренебречь без ущерба для функциональности прибора. Кстати, если выберете ядро Cortex-M4, то получите еще и аппаратную поддержку вычислений с плавающей запятой с очень приличной производительностью.

Если вы видели пдф на энкодер в начале поста там сказано что рисок у них может быть аж до 65535
это 0.0055 физических градуса!!! Улыбаюсь

Мне как-то попадался энкодер еще и с редуктором, т.е. на один оборот вала у него было несколько оборотов лимба. Разрешение было вообще какое-то совершенно фантастическое.

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

Или еще как простейший вариант - вести отсчет от начального нейтрального положения рукоятки джойстика, пока ее еще не двигали.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
stoctman
Читатель

az
Offline Offline

« Ответ #6 : 05-03-2015 17:23 » 

Или еще как простейший вариант - вести отсчет от начального нейтрального положения рукоятки джойстика, пока ее еще не двигали.
Действительно это ещё проще
В общем вы думаете что если использовать мощное ядро то и энкодеров ненадо? магниторезисторов будет достаточно?
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 05-03-2015 18:21 » 

Я бы Вам ещё посоветовал рассмотреть вариант нелинейной характеристики джойстика. То есть ближе к середине чувствительность сделать поменьше, чтобы можно было отрабатывать небольшие точные перемещения, а ближе к краям, наоборот, побольше, для быстрых и грубых движений. Например, выходной сигнал будет пропорционален квадрату смещения рукоятки. В этом случае можно будет обойтись менее точными АЦП и датчиком с меньшим диапазоном значений и при этом не потерять ни в разрешении, ни в амплитуде.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
stoctman
Читатель

az
Offline Offline

« Ответ #8 : 09-03-2015 18:41 » new

Я думал этим будет заниматься внешний софт уже на пк который перехватывает данные с физического устройства и обрабатывает
так как это нужно пользователю типа вот этого http://www.xedocproject.com/joystickcurves.html
а устройство должно обеспечивать как можно точнее, быстрее и больше данных для реального соответствия выбранным кривым.
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines