Линейные энкодеры
Как сделать энкодер вращения не раз писалось и здесь в форуме и нете много чего есть.
Но давайте подумаем как можно сделать линейный энкодер. Есть мысль (может скажу глупость - тогда не пинайте) использовать принцип, а может и апппаратную часть оптической мыши?
А какие это даст примущества? В чем смысл перехода на линейку? И чем размечать линейку с нужной точностью?
Если смысл в том, чтобы в любой момент знать точные координаты, то опять же остро стоит вопрос о кодировании разметки на линейке и ее считывании - сенсор не читает ведь цифры, ему их нужно закодировать. И обработать сигнал в реальном времени от такого сенсора задачка не тривиальная.
Можно сенсор и от мышки использовать - он сам вычисляет величину смещения, только перемещение должно быть не слишком быстрым.
Может использовать электронную рулетку? Только у нее точность не слишком высокая.
А какие это даст примущества? В чем смысл перехода на линейку? И чем размечать линейку с нужной точностью?
Если смысл в том, чтобы в любой момент знать точные координаты, то опять же остро стоит вопрос о кодировании разметки на линейке и ее считывании - сенсор не читает ведь цифры, ему их нужно закодировать. И обработать сигнал в реальном времени от такого сенсора задачка не тривиальная.Можно сенсор и от мышки использовать - он сам вычисляет величину смещения, только перемещение должно быть не слишком быстрым.
Может использовать электронную рулетку? Только у нее точность не слишком высокая.
Смысла в принципе нет, если нет люфтов. Но линейку можно использовать как отдельную от ЧПУ индикацию с набором примитивов управления.
Обработать данные с сенсора - задача тривиальная, даже при скорости 1м в сек и 0.01 получаем 100кГц импульсов. Любой МК справится.
Мышки сейчас быстрые. И точность можно повысить, поменяв линзу на побольше. Я на базе мышки хочу для начала сделать точный тестер смещения, 0.001 и выше - для выставления направлющих.
Смысла в принципе нет, если нет люфтов. Но линейку можно использовать как отдельную от ЧПУ индикацию с набором примитивов управления.
Обработать данные с сенсора - задача тривиальная, даже при скорости 1м в сек и 0.01 получаем 100кГц импульсов. Любой МК справится.
Мышки сейчас быстрые. И точность можно повысить, поменяв линзу на побольше. Я на базе мышки хочу для начала сделать точный тестер смещения, 0.001 и выше - для выставления направлющих.
Задача тривиальная, если
- используется мышиный сенсор с определением смещения в сенсоре,
- не определяются абсолютные координаты,
поскольку мышиный сенсор по сути инкрементный.
Тривиальность сразу пропадает, когда нужно определить абсолютные координаты.
Каким образом
- кодировать абслютное расстояние на линейке (грубо говоря, числа),
- нанести разметку с требуемой точностью,
- распознать считанную информацию?
Скорость работы сенсора ADNS-2620 (который обычно стоит в мышах) 12 in/sec (примерно 0,3 м/с).
Это приемлемая скорость поступления информации в микроконтроллер, если только считывать информацию о смещении. Если обрабатывать кадр для распознавания меток расстояния, скорость считывания кадров сильно упадет., поскольку нужно будет считать всю матрицу пикселов (18*18),
а потом еще и распознать. Опыт распознавания изображений есть?
P.S. Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf
Видел такую штуку в струйном принтере, вроде-бы HP690.
На печатающей головке - датчик, который смотрит на риски, нарисованные на полоске из прозрачной плёнки. Полоска натянута вдоль направляющей, по которой головка ездит.
Смысла в принципе нет, если нет люфтов. Но линейку можно использовать как отдельную от ЧПУ индикацию с набором примитивов управления.
В серво - это единственное применение… Из-за ненадежности.
Представь, ты говоришь своему французскому 20-кг другу “А ну-ка брат, слетай как быстренько в тот угол!” и в этот момент с вала слетает энкодер…
Будет большой “Бум!!” и “Вах!” куча матов и прозрение, что порталы тоже летают.
С линеечкой, если это- не стеклянная штука в герметичном корпусе, это может произойти на раз… Стружка там, еще что…
Стеклянные штуки на блину более метра- просто бешенно дороги…
А просто для выяснения координат умные западные дяди уже давно используют магнитную полоску и кучу всяких читалок…
Наклеил рядом- и читай на таблищще крупными буквами, где он счас…
Тривиальность сразу пропадает, когда нужно определить абсолютные координаты.
Каким образом
- кодировать абслютное расстояние на линейке (грубо говоря, числа),
- нанести разметку с требуемой точностью,
- распознать считанную информацию?
При начале работы станка по датчикам устанавливаемся в 0, потом танцуем от этого. Вот вам и абсолютные координаты.
Скорость работы сенсора ADNS-2620 (который обычно стоит в мышах) 12 in/sec (примерно 0,3 м/с).
Это приемлемая скорость поступления информации в микроконтроллер, если только считывать информацию о смещении. Если обрабатывать кадр для распознавания меток расстояния, скорость считывания кадров сильно упадет., поскольку нужно будет считать всю матрицу пикселов (18*18),
а потом еще и распознать. Опыт распознавания изображений есть?P.S. Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf
Я знаком с мышиными датчиками.
Зачем читать матрицу и обрабатывать кадры? Использовать абсолютный выход.
Еще - при использовании размеченной поверхности можно добиться точных результатов по перемещениям.
Также можно добавить абсолютный код через например каждый сантиметр. Никто не запрещает периодически юстироваться не спеша.
Вообще мне эта тема интересна, готов поучаствовать более конкретно.
Когда-то давно прикоснулся к теме измерения малых абсолютных перемещений. Две кварцевых полированных стекляшки, на которые напылен слой хрома в виде гребенок. А теперь представим две одинаковых расчески, которые наложены друг на друга зубьями навстречу, и одна перемещается по другой. При этом зубья одной периодически перекрывают просветы между зубьями другой. Вот так же и эти стекла. Точность определяется шириной получаемых вакуумным напылением и фотолитографией (тогда это был УФ) зубьев гребенки. Одна гребенка неподвижно закреплена, вторая связана с перемещаемым обьектом. А дальше оптическое преобразование и подсчет импульсов. Очень точно (доли микрона), но механически непрочно. Подобный принцип (с интерполяцией) применен в принтере, как описано выше.
Зачем читать матрицу и обрабатывать кадры? Использовать абсолютный выход.
Еще - при использовании размеченной поверхности можно добиться точных результатов по перемещениям.Также можно добавить абсолютный код через например каждый сантиметр. Никто не запрещает периодически юстироваться не спеша.
Вообще мне эта тема интересна, готов поучаствовать более конкретно.
Давайте, попробуем, все же, перейти от общих формулировок к конкретике.
По поводу датчика из мыши:
- Вывели портал в 0, считали координаты.
- Начали перемещаться, в это время считываем с датчика инкремент по оси. Что будет при пропуске кадра или сбое в вычислении корреляции между кадрами? Ошибка в определении текущих координат.
- Предположим, что через каждый сантиметр нанесены специальные метки. Как определить номер метки? Как вместе с меткой закодировать число? Предположим, что сделали это какой-то структурой из черных и белых точек, для метровой линейки их будет 100. Считали изображение, нужно сопоставить его с эталонными (их 100), и определить, какому оно соответствует (по корреляции, видимо). Не уверен, что микроконтроллер типа PIC16 или PIC18 в состоянии это быстро сделать. А если учесть колебания освещенности, загрязнения, то задача становится еще сложнее.
По поводу магнитного датчика:
Этот датчик, мне кажется более приспособленным к реальной жизни. Но тоже есть вопросы.
- Каким образом наносить и кодировать информацию?
- Как преодолеть зависимость амплитуды (и частоты, если использовать частотное или тональное кодирование) от скорости движения портала? При медленном перемещении можно вообще потерять сигнал.
Есть еще вариант, по такой схеме делают серийные энкодеры - к абсолютному энкодеру вращения прицепляют барабан с тросиком. Тоже есть куча вопросов, но эти делают, и продают серийно. Правда цена…
Я вовсе не противник такого энкодера - если получится его сделать, это будет здорово. Но что-то мне подсказывает, что все не так просто, как кажется на первый взгляд. Хотя, с другой стороны, не боги горшки обжигают, вдруг получится…
Вот я раскорячился.
По поводу приспособления энкодера вращения я думал, единственный вопрос - растяжение (периодическое) тросика. Хотя тонкий стальной тросик с предварительной натяжной иди зубчатым ремнем вроде должен держать нормально, усилия не большие. Вопрос получается в диаметре приводного валика, тут энкодеров из ШД не отдуешся, т.к. 400 импульсов на оборот это мало.
[quote=ATLab;268686]
P.S. Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf
Не могу найтить, выложи куда-нибудь
Вообще-то уже относительно недорогие (порядка 50 баксов) энкодеры уже дают порядка 4к отсчетов на оборот.
А вообще, если уж так делать - это надо делать полноценный двойной плоттер - 4 канала управления шаговиками, 4 входа энкодеров, USB порт… 😉).
Давайте, попробуем, все же, перейти от общих формулировок к конкретике.
По поводу датчика из мыши:
- Вывели портал в 0, считали координаты.
- Начали перемещаться, в это время считываем с датчика инкремент по оси. Что будет при пропуске кадра или сбое в вычислении корреляции между кадрами? Ошибка в определении текущих координат.
- Предположим, что через каждый сантиметр нанесены специальные метки. Как определить номер метки? Как вместе с меткой закодировать число? Предположим, что сделали это какой-то структурой из черных и белых точек, для метровой линейки их будет 100. Считали изображение, нужно сопоставить его с эталонными (их 100), и определить, какому оно соответствует (по корреляции, видимо). Не уверен, что микроконтроллер типа PIC16 или PIC18 в состоянии это быстро сделать. А если учесть колебания освещенности, загрязнения, то задача становится еще сложнее.
- Проблем вроде нет. Но при наличии абсолютных меток выходить в 0 не нужно.
- Никаких сбоев. Их просто нет. В серво-приводе енкодер по умолчанию не ошибается. Не ошибется и у нас.
- Абсолютные метки. Подойдет любой код - двоичный, полосками-отверстиями, валет-дама-туз… Мы читаем его НЕ СПЕША (в случае например чтения матрицы с датчика мыщи) или на лету, в случае двоичного кода. Ничего распознавать никоми образом не нужно, не усложняйте.
По поводу магнитного датчика:
Этот датчик, мне кажется более приспособленным к реальной жизни. Но тоже есть вопросы.
- Каким образом наносить и кодировать информацию?
- Как преодолеть зависимость амплитуды (и частоты, если использовать частотное или тональное кодирование) от скорости движения портала? При медленном перемещении можно вообще потерять сигнал.
Магнитный датчик использовать тяжеловато… Это все-таки более механическое дело в отличие от оптики.
Есть еще вариант, по такой схеме делают серийные энкодеры - к абсолютному энкодеру вращения прицепляют барабан с тросиком. Тоже есть куча вопросов, но эти делают, и продают серийно. Правда цена…
Это без меня.
Я вовсе не противник такого энкодера - если получится его сделать, это будет здорово. Но что-то мне подсказывает, что все не так просто, как кажется на первый взгляд. Хотя, с другой стороны, не боги горшки обжигают, вдруг получится…
Давайте определим для начала цели и задачи. И от этого оттолкнемся.
Есть еще вот такой принцип линейной шкалы (на фотке).
Давайте определим для начала цели и задачи. И от этого оттолкнемся.
Давайте. Я предполагаю, что линейный энкодер нужен для определения в реальном времени текущих абсолютных координат портала. Соответственно, эту информацию можно и нужно использовать для управления двигателем, неважно каким, для задания траектории и скорости движения.
Sergey_Murzinov
Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf
Не могу найтить, выложи куда-нибудь
Выложил: webfile.ru/894231, пароль ADNS2620, доступен до 12 апреля 2006 г.
Давайте. Я предполагаю, что линейный энкодер нужен для определения в реальном времени текущих абсолютных координат портала. Соответственно, эту информацию можно и нужно использовать для управления двигателем, неважно каким, для задания траектории и скорости движения.
Упаси тебя Будда использовать это для управления сервомоторами без резервного определения перемещения по валу мотора. Иначе- порталы ЛЕТАЮТ!
Ты наворачиваешь станок цепью из десятка деталей, которые могут сломаться, порваться, заклинить, замараться… Вместо одного энкодера , который ближе всего в приводу.
Ты увеличиваешь в десятки раз вероятность отказа…
А если тебе ставить резервку- так смысл всего этого дубляжа?
Если шпиндель точен ( а он точнее и стабильнее линейного энкодера) - то ты просто наворачиваешь станок лишней и дорогой системой.
ИМХО- либо промышленные дорогущие стеклянные шкалы, либо дешевый энкодер на вал.
Третьего- не дано…
Ппредлагаю простой линейный энкодер… 😁
На столе… полотно от рулетки, а на движущейся части… WEB - камера с нестандартной оптикой… и фонариком, вероятно… Дело за небольшим - грамотным ПО!
(Шутка с долей истинны!)
Ппредлагаю простой линейный энкодер… 😁
На столе… полотно от рулетки, а на движущейся части… WEB - камера с нестандартной оптикой… и фонариком, вероятно… Дело за небольшим - грамотным ПО!
(Шутка с долей истинны!)
Не, web-камера точно не подойдет, вот она стоит у меня перед глазами 6408480 USB2- все движения получаются смазанными. Прикидываю, как от нее изображение забрать в свою программу, выходит, что без Windows никак. А про то, что в Windows плохо управлять двигателями станка уже много написано. Да и обрабатывать изображение нехилое быстродействие нужно - фотография в BMP занимает 921 кбайт, уж лучше мышиный датчик. Не всегда много пикселей хорошо.
Народ на сайте www.usdigital.com/products/lin/ есть описание линеных энкодеров. Вот только не могу всосать как получают сигналы двух каналов выходов
Прикольно. Линейку на коленке делать. Это фокус. Всё таки как вы собираетесь риски например, с шагом 0,02 и с высокой точностью на линейку наносить?
Допустим, не на стекло, а на лавсановую плёнку. Всё равно, как?
ATLab,
линейка с абсолютными координатами, это ещё сложноватистей. Принцип то простой, контроллер с памятью и интерфейсным портом на головку ставится. Для снижения обрабатываемого объёма данных, сброс счётчиков на каждой индеферентной метке, например, через каждые 20 мм. Для скорости выставки, каждая метка кодируется.
Но сделать это (естественно точно) не так уж просто. Поэтому хорошая линейка дорого стОит, примерно 1$ - 1мм.
ATLab,
линейка с абсолютными координатами, это ещё сложноватистей. Принцип то простой, контроллер с памятью и интерфейсным портом на головку ставится. Для снижения обрабатываемого объёма данных, сброс счётчиков на каждой индеферентной метке, например, через каждые 20 мм. Для скорости выставки, каждая метка кодируется.
Но сделать это (естественно точно) не так уж просто. Поэтому хорошая линейка дорого стОит, примерно 1$ - 1мм.
А я не спорю, конечно, получить абсолюгные координаты сложнее. Только я не вижу смысла делать линейный энкодер без этого, а для относительных вполне достаточно энкодера на валу.
Как обработать сигнал с камеры я представляю - бОльшую часть трудовой биографии занимаюсь цифровой схемотехникой, микропроцессорами и микроконтроллерами, в том числе и программирую - может поэтому и не предвижу легкости в обработке (распознавании) изображения. Цифровой обработкой изображений интересовался еще в студенческие времена - элементная база за это время изменилась, а принципы обработки и формулы - нет.
Убежден, что простым микроконтроллером типа PIC16, PIC18 в реальном времени слежения за линейкой и распознавания абсолютных меток не сделать, не нужно иллюзий по этому поводу.
Не, web-камера точно не подойдет…
Далее… А сенсор, аналогичный сенсору сканера? Линией вдоль линейки? Закодировать абсолютные координаты в ширине рисок линейки (допустим, десяток узких - синхронизирующих, за ними широкая - стартовая и следом кодовая комбинация из широких и узких? При этом, если сенсор будет сразу пару комбинаций, допустим, будет обозревать… то абсолютную координату сможет вычислить в любом положении… ?!
Разместить счёт для авторских отчислений? 😅
Допустим, на лазерном принтере риски на шкалу напечатаете. Например, 600 DPI, составит 0,0423 мм/шаг, предположим, машине с такой линейкой надо на 0,2 мм двинуться. 0,2:0,0423=4,728 шага. То есть 5 полных шагов. 5*0,0423=0,2115. При этом погрешность перемещения составит 0,2115-0,2=0,011 На сотне таких перемещений погрешность составит более миллиметра, на тысяче - 11,5 мм.
И дело даже не в дюймах, а в некратности шагу машины.
Само собой, принтер штука не точная, шестерёночки пластиковые, протяг не совершенный, такая шкала точность будет иметь + 0,5 мм на 0,25 м.
Не верите - файлик приложенный распечатайте, например на HP 6L и металлической линейкой по ГОСТ 427-75 измерьте.
Рачпечатали?
Полосочки по фону видите? Муар называется. Это вы как раз вышеописанную погрешность наблюдаете. Не даст он вам точно работать, да и полосатить всегда будет. Шкала конечно хилая, 1000 линий, 0,25мм/шаг, на серъёзной шкале всё будет гораздо хуже.
Кто то скажет - для хобби пойдёт. Ну если хотите вместо кругов овалы резать, фоны полосатить, размеры не выдерживать, и на миллиметры и сантиметры уезжать - тогда пожалуйста…
В общем кому время не жалко терять, балуйтесь 😃
BALAL,
Примерно так и делается, так что авторские отчисления не грозят 😃
ATLab,
“получить абсолютные координаты сложнее. Только я не вижу смысла делать линейный энкодер без этого, а для относительных вполне достаточно энкодера на валу.”
Как раз таки последние продвинутые энкодеры имеют кучу смещённых шкал, и легко считывают абсолютное положение.
А линейка это ЛИНЕЙКА.
Galant1,
“Иначе- порталы ЛЕТАЮТ!”
Дальше концевика не улетит 😃