roboforum.ru

Чем же еще заниматься в новый год, если не роботостроением? Вот решил возобновить проект своего робота и доделать ему наконец правильную одометрию, чтобы он мог совершать хоть какие-то осмысленные движения. Собственно система у меня такая- колёсико от мышки ( одновременно и колесо робота) приводится непосредственно мотором, а в через прорези в колесе стоит обычный энкодер ( не квадратурный). Всего на на колесе 10 рисок, то есть разрешение 36 градусов, или 7.6 миллиметров по длине окружности колеса. Идея обработки ( с оглядкой на PID регулирование) - посчитать число прерываний от таймера 0 пока колесо проходит один сектор ( то есть от фронта до фронта с энкодера).
Результаты таковы: если поставить нулевому таймеру единичный предделитель, количество его прерываний на один сектор при минимальном и максимльном заполнении (120 и 220 для восьмибитного шима) меняется примерно в 2 раза- то есть при 80 их 4, а при 1 -220, но это в среднем ( вообще в 16-ричном виде 04ХХХХ или 01ХХХХ). Есть если смотреть мгновенные значения, то есть выбросы от нуля до пяти при любом заполнении, то есть точно определить, какое сейчас заполнение по количеству прерываний невозможно. Ну и ПИД ( по крайней мере пропорциональная часть) получается нереализуемым. Поиграл с потенциометром, задающим порог срабатывания- без особых результатов.

Так и должно быть.

С колеса можно снимать 2 параметра:
1. Относиттельное положение колеса (от начала измерений) - сумма сигналов
2. скорость движения - время между метками (то, что плавает сильно)

В задачу можно ввечти ограничивающий фактор (ускорение) - скорость изменения скорости. То есть следующай измеренная скорость не может отличаться от предыдущей на величину ускорения!

Ошибка измерения времени между прорезями носит не однонаправленный характер (не накапливается), поскольку зависит от технологических отклонений прорезей. Это позволяет получить лучшие значения скорости усреднением пары последних значений.

Вот, может что-то из этого поможет.

Усреднение буду вводить обязательно ( скорее всего по двум или четырем значениям, чтобы просто дернуть rol`ом). Вообще про совершенно непредсказуемые результаты я несколько слукавил, так как значения писались в епромку, по четыре байта на измерение, то есть не очень быстро (можно конечно все засунуть короткий отрезок в SRAM и потом загнать в епром, но только на асме это писать приятного мало). Некая закономерность там есть, в среднем значение остается постоянным, но причину выбросов типа переполнения (FF FF FF FF) я понять не могу. Контроллер не сбрасывается, питания вроде хватает. такие вещи сразу можно фильтровать программно, что я и пытаюсь сделать, но результатов пока нет (не проверял, некогда). В общем, о тестах доложу.

что бы на асме это писать приятного много было, надо поставить FRAM и наспупит вам много счастья в новом году...

Вообще, похоже что при малых скоростях наблюдается банальный дребезг оптических контактов. Я был точно, на 100% уверен, что для оптических энкодеров его нет (хотя откуда я это взял уже не помню). Вывод такой делаю потому что на расколбас сильнее на малых скоростях, на больших оборотах и соответственно при боьшей скорости "оптического нажатия" дребезг меньше. Буду вводить антидребезг (теперь на Си), правда когда-неизвестно. Банальное ожидание тут не покатит, так как скорость движения может существенно меняться. Придется отрабатывать отдельно и фронт и спад импульса с компараторов ( у меня щас только фронт). Как сделаю-доложу.
Собственно, это в принципе относится и к миниботу тоже, я так понимаю там тоже обычный оптический энкодер.

Для точного измерения (чтобы защититься от "дребезга") нужно использовать сдвоенные энкодеры - когда один переходит границу другой точно посредине полосы - тогда можно легко высчитать когда настоящий переход, а когда "дребезг" .

Ну дребезг не такой уж долгий, поэтому его смело можно откидывать (в моём применении точно). Например, обработкой первого фронта/спада из импульсов в пачке дребезга- тогда аддитивный дребезг вычтется при вычислении длины импульса. Я думал вообще сделать очень тупо- не реагировать на фронт, пришедший раньше, чем середина устанавливаемой длительности + какая-то экспериментальная постоянная. В этот момент как раз будет спад импульса, и может возникнуть дребезг. Но это не будет универсальное решение- если вдруг при регулировании колесо пойдет слишком быстро (в два раза быстрее необходимого) , то фронт реального импульса не будет обработан.
Собственно, рисунки:

steel_monkey писал(а):Ну дребезг не такой уж долгий, поэтому его смело можно откидывать (в моём применении точно). Например, обработкой первого фронта/спада из импульсов в пачке дребезга- тогда аддитивный дребезг вычтется при вычислении длины импульса. Я думал вообще сделать очень тупо- не реагировать на фронт, пришедший раньше, чем середина устанавливаемой длительности + какая-то экспериментальная постоянная. В этот момент как раз будет спад импульса, и может возникнуть дребезг. Но это не будет универсальное решение- если вдруг при регулировании колесо пойдет слишком быстро (в два раза быстрее необходимого) , то фронт реального импульса не будет обработан.

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

Тут я с Вами полностью согласен, раз уж топик так называется. По уму, так и надо делать, но это несколько усложнит реализацию- два энкодера на колесо и два диска это как минимум механическая трудность.
У меня например и диапазон скоростей предполагается не очень широким (2-2,5 раза, не больше), так что остановка предотвращается проверка на минимальное значение ШИМа. Выжимать из коллекторных моторов да еще и практически без редуктора малые обороты весчь явно неблагодарная.

steel_monkey писал(а):Тут я с Вами полностью согласен, раз уж топик так называется. По уму, так и надо делать, но это несколько усложнит реализацию- два энкодера на колесо и два диска это как минимум механическая трудность.
У меня например и диапазон скоростей предполагается не очень широким (2-2,5 раза, не больше), так что остановка предотвращается проверка на минимальное значение ШИМа. Выжимать из коллекторных моторов да еще и практически без редуктора малые обороты весчь явно неблагодарная.

Два диска это зачем? Обычно либо на 1 диске рисунок сразу под 2 параллельно установленных энкодера, либо энкодеры ставят со сдвигом друг относительно друга.

В общем, дребезг нормально отсекается по тому принципу, что я указал в ПДФке. Скорость удается регулировать в 2 раза, дальше тяга становится неравномерной, колесо останавливается, потом некоторое время робот ждет, дает газу, тормозит, снова останавливается.. короче, почти автоколебания. Но с этим мне щас, чесно говоря, разбираться лениво, так как 2 раза это в принципе совершенно достаточно. Единственный реальный недостаток- никакого позицианирования и навигации с такие управлеием не сделаешь, так как скорость устанавливается не сразу. То есть по прямой едем идеально, но из режима в режим переходим криво . Как считать и повороты и скорость, а главное это еще и регулировать, , не знаю, но чуствую, геммороя там хватает.
Вообще, такую штуку можно и к миниботу пределать- там же тоже вроде энкодер. Правда вроде поточнее.
Кстати, наваял тут хрень такую. Мож кому интересно

а почему на вражеском языке-то?

2steel_monkey: Я вообще занимался в своё время этой задачей (одометрия), получилось что правильный путь пройти можно с в 2-4 раза более высокой точностью по кликам, чем максимальное отклонение от заданных положений колёс в середине пути. У вас как результаты такие?

У меня щас просто нет такого понятия, как заданное положение колес ( кстати, фразу я так до конца и не понял, какая траектория имеется в виду). Сейчас у меня установка скорости на каждое колесо вообще дается по времени (я вообще не люблю прогать, а тут такие перспективы блин), едем левым быстрее правым медленнее 100 тактов, потом перестраиваем скорость ну и т.д.. В итоге, траектории прямая и круг получаются идеально ( с поправкой на то, куда у меня на старте вывернуто переднее колесо, его надо заменить просто на опору для устранения этого эффекта, ну и еще там можно поиграть с коэффициентами в обратной связи для достижения большей плавности перестройки/старта). Если имеется в виду какая-то траектория, отличная от двух указанных, то кроме как разбивать её на элементарные участки, мне в голову ничего не приходит. Ну а тут получаются большие ошибки сопряжения траекторий- напимер, повернуть на 90 градусов будет довольно проблемматично, если вообще возможно, так как входить в режим ( режим имется в виду по скорости колес) дольше, чем в нем находиться. Возможно, как я уже сказал, надо убрать инерционность ( третье колесо, оно у меня поворачивается, и небыстро), и поиграть еще немного с алгоритмами, ну улучшить эту схему на порядок мне, например, не кажется возможным.
Тут еще надо учитывать, что у меня точность энкодеров 36 градусов, то есть разрешается только 10 положений на оборот. Как в таком случае можно ходить по кликам, я не очень представляю. Я вообще не очень представляю, как ходить по кликам по сложной траектории- в любом случае, необходимо отслеживать и скорость, и клики, потому как сначала повернуть и потом подъехать это не то же самое, что сначала подъехать, а потом повернуть, даже если у колес будут интегратьно одинаковые пути. Как эти два алгоритма совместить, я, лично, всилу своей компьютерной неграмотности, не представляю. Разве что ввести еще одно пропорциональное слагаемое, как для скорости.

P.S. А текст на вражеском, потому как для врагов . Пусть знают наших, не все же шарпы да сонары юзать. Пусть посмотрят на орудие пролетариата.

Я баловался на мотор-редукторе от стеклоподъемника с колёсным узлом робоклуба и их энкодерами в 120 кликов, а делал я следующее:

По моей задумке дравер двигателей должен отрабатывать очередь из команд следующего вида: (T,VA1,VB1,VA2,VB2), где T-количество тактов, VA1 - начальная скорость левого колеса, VB1 - начальная скорость правого колеса, VA2 - конечная скорость левого колеса, VB2 - конечная скорость правого колеса.

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

При этом сделать еще простейшую обработку ошибок:
1. Если VA1,VB1 следующей команды не равны VA2,VB2 предыдущей, или нулям (если предыдущей не было), тогда команда неверная и пропускаем её;
2. Если последнюю команду из очереди выполнили, а там новой нет или все пропустили - добавляем в очередь команду с торможением за минимально возможное время (зависит от текущих скоростей колёс).

А у вас какой формат команд? Или вы прямо скорость задаёте и уже её отрабатываете какое-то время?