roboforum.ru

Digit писал(а):Dead, ну как? Развитие тема получила? А то я что-то из концовки не понял, что реализовано из протокола (Ls, Rs, Lf, Rf, DL, DR, T) + ПИД-регулятор... И статейку в вику обещался

Чего-то пока закрутился я со временем свободным туго. Реализован протокол полностью + ПИД регулятор, выложены прошивка и исходники вроде, если что - довыложу, если забыл чего. Формат команд описан в вике, файлики там же лежат. Статейку пока времени нет

Digit писал(а):Кстати, ты тут говорил, что у девантеха нет возможности поворотов на скорости. А она есть!
По I2C задается регистры speed и turn. Подробнее можно там почитать.

Не возможности поворота у них нет, а возможности входить в поворот на скорости, или ты предлагаешь не плавно входить в поворот, а резко начать по дуге ехать?

Digit писал(а):А вот очереди команд у них нету, это да.

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

Правда у меня тоже пока с обратной связью не супер ситуация, но доделать её - копеечный вопрос, тупо прописать в моей прошивке размещение счетчиков в переменных i2c и текущей ситуации (% выполнения команды, счетчик команд, отклонение текущие по каждому колесу по расстоянию и скорости).

=DeaD= писал(а):Не возможности поворота у них нет, а возможности входить в поворот на скорости, или ты предлагаешь не плавно входить в поворот, а резко начать по дуге ехать?

Чет я не понял. Ты о чем? В чем разница терминов "поворот на скорости" и "вход в поворот на скорости"? По-моему, это одно и то же...

На всяк случай повторюсь: как я уже говорил, у них есть вариант руления шасси в режиме, когда задается speed и turn.
Для двух движков скорости считаются так:
скорость движка №1 = speed - turn
скорость движка №2 = speed + turn
Т.е. едем прямо: speed = какую_надо, turn=0
Надо повернуть по дуге не сбавляя скорости: speed=как_и_прежде, turn=нужное_значение. Один движок замедлится, а другой ускорится. И бот поедет по дуге не сбавляя хода (точка на середине расстояния между колесами будет описывать дугу с мгновенной скоростью speed).

Digit писал(а):Чет я не понял. Ты о чем? В чем разница терминов "поворот на скорости" и "вход в поворот на скорости"? По-моему, это одно и то же...

Разница в том, что ты не сможешь резко поменять скорость колеса в реальности и у тебя всё съедет. Ты когда даешь команду с места рвануть вперед, как думаешь, у тебя правда робот в следующую секунду с полной скоростью вперед помчится или как-то более плавно начнет разгон?

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

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

А-а! Вооот ты о чем!
Теоретически, дуга в их случае должна быть с переменной кривизной, т.е. turn меняется от 0 до нужного значения... Но без обратной связи, канеш, не получится. Это очевидно.
А твой универсальный протокол позволяет все это учесть? Т.е. поставить приоритеты на время выполнения, точность поддержания скорости или точность следования траектории? А то это ж две большие разницы: участвовать в состязании на самое точное перемещение по квадрату и проезд через пол квартиры на встречу хозяину, чтоб тапочки выдать. В первом случае нужна траектория один в один, а во втором случае - главное время выполнения задания, а погрешность в движении - это дело десятое.

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

Digit писал(а):А твой универсальный протокол позволяет все это учесть? Т.е. поставить приоритеты на время выполнения, точность поддержания скорости или точность следования траектории? А то это ж две большие разницы: участвовать в состязании на самое точное перемещение по квадрату и проезд через пол квартиры на встречу хозяину, чтоб тапочки выдать. В первом случае нужна траектория один в один, а во втором случае - главное время выполнения задания, а погрешность в движении - это дело десятое.

Всё учесть не позволяет, а вот приоритет на точность перемещения (следования траектории) есть. Сделать вариант где главное время выполнения - раз плюнуть - поставить одно условие во втором варианте которого убить ПИД-регулятор заменив его тупой формулой ШИМ=функция(ТребуемаяСкорость).

Добавлено спустя 7 минут 8 секунд:

Виталий писал(а):Точность выполнения я думаю нам шибко не нужна, т.к. система должна иметь обратную связь через среду, ну линию там например...

Я в ауте... можно и на автомобиле с люфтом руля +/- 10° ездить, обратная связь ведь есть?

Может у вас в line-following и легко каждую долю секунды обратную связь получать и решение принимать, так ведь и не делает там никто ПИД-регулятор, а мне вот с визуальными маяками не с руки каждые 10 см останавливаться и осматриваться куда сейчас можно ехать. Я же не сказал что вот уж прямо каждому весь этот функционал надо будет, отключаемым сделать и всё эту фишку только если её не надо - нафиг тогда вообще все эти навороты, которые я прописываю, если вы каждую долю секунды обратную связь имеете - вам и очередь команд не нужна и вообще не нужно никакого протокола кроме того, сколько ШИМ выдать на каждый движок, так это у меня тоже есть уже

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

Каков в вашем случае алгоритм и почему для него нужна точность? Чтобы объехать препятствие точность сильная не нужна при наличии нормальных датчиков.

Может у вас в line-following и легко каждую долю секунды обратную связь получать и решение принимать, так ведь и не делает там никто ПИД-регулятор,

Это неправда, делают там ПИД регулятор, т.к. без него не ездиит нормально. =)

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

Каков в вашем случае алгоритм и почему для него нужна точность? Чтобы объехать препятствие точность сильная не нужна при наличии нормальных датчиков.

Я же только что пояснил на примере с автомобилем. Выводы еще не сделаны? Ладно, сделаю их сам - ездить вы на таком автомобиле сможете, только на значительно меньшей скорости, чем на нормальном. А так конечно - можно и на нём доехать хоть куда.

Виталий писал(а):

Может у вас в line-following и легко каждую долю секунды обратную связь получать и решение принимать, так ведь и не делает там никто ПИД-регулятор,

Это неправда, делают там ПИД регулятор, т.к. без него не ездиит нормально. =)

Чего-то ты сам себе противоречишь, так нужна там точность или нет? Весь мой алгоритм на ПИД-регуляторе и основан, ты говоришь, что он нужен, а вот мой алгоритм нет это как? Он типа нужен, но только по скорости, а не по расстоянию? Или что?

И вообще мы говорим о разных концепциях движения - ты говоришь, что каждую долю секунды мы будем перепланировать куда ехать, а я говорю о другом варианте, когда я построил путь на карте и начал по нему ехать, при возникновении ЧП я перестраиваю путь.

Я же только что пояснил на примере с автомобилем. Выводы еще не сделаны? Ладно, сделаю их сам - ездить вы на таком автомобиле сможете, только на значительно меньшей скорости, чем на нормальном. А так конечно - можно и на нём доехать хоть куда.

Люфт - ошибка статическая, а потому все гораздо проще. =) Скорость не снизится, повысятся требования к системе управления. =) Но это флейм на самом деле.

Чего-то ты сам себе противоречишь, так нужна там точность или нет? Весь мой алгоритм на ПИД-регуляторе и основан, ты говоришь, что он нужен, а вот мой алгоритм нет это как? Он типа нужен, но только по скорости, а не по расстоянию? Или что?

И вообще мы говорим о разных концепциях движения - ты говоришь, что каждую долю секунды мы будем перепланировать куда ехать, а я говорю о другом варианте, когда я построил путь на карте и начал по нему ехать, при возникновении ЧП я перестраиваю путь.

Про разные концепции примерно правильно. Тебе ничего не стоит испытать твою концепцию на практике, т.к. думаю реалботовская платформа позволяет.
Мне кажется она будет страдать, по той причине, что при движении в помещении ЧП обычно на протяжении всего этого движения. =) Хотя зависит от алгоритма конечно.

Виталий писал(а):Люфт - ошибка статическая, а потому все гораздо проще. =) Скорость не снизится, повысятся требования к системе управления.

Неисправный глючный ГУР в качестве примера тебя устроит? Который то усиливает твоё движение, то наоборот мешается?

Виталий писал(а):Про разные концепции примерно правильно. Тебе ничего не стоит испытать твою концепцию на практике, т.к. думаю реалботовская платформа позволяет. Мне кажется она будет страдать, по той причине, что при движении в помещении ЧП обычно на протяжении всего этого движения. =) Хотя зависит от алгоритма конечно.

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

2=DeaD=

Почти полностью согласен с твоим принципом управления. Но, сделаю оговорку Моя идея предполагала по-сути точно такое же управление, с разницей в том, что у меня передаётся не время выполнения команды, а расстояние, которое должно пройти колесо. Объясняю чем мне больше нравится такой подход: в твоём случае нам наверняка понадобится функция, ставящая зависимость между величиной ШИМ и скоростью вращения; она наверняка будет нелинейна и её будет сложно получить. У меня же нужна функция, которая поставит зависимость между количеством тиков энкодера и пройденым расстоянием - а она уже линейна. Ну и сама концепция передачи расстояния вместо времени мне более по душе Хотя это уже не принципиально.

Интересно услышать ответ

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

vintch писал(а):2=DeaD=

Ну нифига себе какие люди! Приветствую наконец-то в онлайне на этом форуме!

vintch писал(а):Почти полностью согласен с твоим принципом управления. Но, сделаю оговорку Моя идея предполагала по-сути точно такое же управление, с разницей в том, что у меня передаётся не время выполнения команды, а расстояние, которое должно пройти колесо. Объясняю чем мне больше нравится такой подход: в твоём случае нам наверняка понадобится функция, ставящая зависимость между величиной ШИМ и скоростью вращения; она наверняка будет нелинейна и её будет сложно получить. У меня же нужна функция, которая поставит зависимость между количеством тиков энкодера и пройденым расстоянием - а она уже линейна. Ну и сама концепция передачи расстояния вместо времени мне более по душе Хотя это уже не принципиально.

1. Не понял, функция которая определяет величину ШИМ в зависимости от скорости нужно будет в любом случае - тебе всегда нужно пройти расстояние или время с какой-то скоростью (что то же самое, что и расстояние, D=(S1+S2)*T/2, где D - расстояние в твоём варианте, и в моём варианте S1,S2 - начальная и конечная скорость и T - время).

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

3. На всякий случай повторюсь - я не предполагал нигде рассчитывать ШИМ который выдавать на движки и его передавать, я предлагал всегда передавать в терминах расстояния в "кликах" и времени в "тиках"

vintch писал(а):Интересно услышать ответ

Так это всегда пожалуйста

Ну нифига себе какие люди! Приветствую наконец-то в онлайне на этом форуме!

Спасиб

Воот чёрт. Я понял где я перепугался твоей идеи. Когда я читал "задавать скорость", то почему-то сразу представлял себе нелинейную формулу расчёта, устанавливающую зависимость ШИМ = f(скорость). Но только сейчас до меня дошло - скорость это то, что мы по-сути передадим ПИД регулятору. А тот уже будет подбирать ШИМ. И даже в случае нелинейности (незначительной; а у нас именно таковая и будет) он нормально подберёт значение.
В таком случае вопрос снимается и извиняюсь за преждевременно поднятую панику)))

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

Тогда последнее. Осторожно, но задам вопрос: зачем передавать скорости движения, предварительно их расчитывая, если цель наша - совершить перемещение, чьей характеристикой в первую очередь является расстояние; а время его преодоления (что и есть скорость) для нас по-сути не важно?
О как)
Я к тому, что мне кажется проще, чтобы управляющая программа передавала просто сразу цепочку векторов модулю и может быть дополнительно несколько параметров движения, повышающих оптимальность движения в зависимости от местности (ну к примеру на льду она один раз установит минимальные ускорения и дальше по-прежнему будет гонять только цепочки векторов; а ДД сам будет оч плавно разгонять/тормозить шасси), а не последовательность из скоростей движения, которой нужно следовать. Таким образом мы просто упрощаем жизнь верхнему уровню, разгружаем каналы передачи данных (ввиду практического исключения пакетов-корректировок) Как ты считаешь?
p.s. пора спать. Что-то меня совсем заносит уже, сам не понимаю чё пишу...

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

Окей
Ускорение и замедление будет задаваться отдельными пакетами. Их формат полагаю пока не важен.
Контроллер двигателей обязательно содержит очередь (такая себе queue). Все команды дописываются в неё.
А далее же всё идёт по аналогии и преобретает где-то такой вид: Rd, Ld, S. Где S - скорость (причём она может задаваться вместе с ускорением, также один раз; но тогда мне кажется будет много "левых" пакетов на конфигурирование. Хотя тут спорить можно...). Rd - дистанция для правого колеса, Ld - дистанция для левого колеса.

Но здесь сразу всплывают недостатки, один из которых - жесткая привязанность к заданному ускорению и неудобство его изменения. Так что можно попробовать оформить пакет примерно таким образом: Rd, Ld, S, A. Где A - некий коэффициент ускорения. Но такая комбинация несколько урезает нам количество потенциальных маневров. Таким образом можно прийти вот к такому варианту: Rd, Ld, S, Ra, La. Где параметры Ra и La соответственно ускорения (а также и замедления - это одна и та же величина, только в последнем случае контроллер сам множит её на -1) для левого и правого колеса.
А в довершении всего, можно сам формат пакета сделать плавающим. То есть величины S, Ra и La задаются один раз отдельным, "сервисным" пакетом и запоминаются как значения по умолчанию. И на будущее, если в пакете отсутствует какае-то из этих величин, то она берётся из заранее установленых.

Так что пакет может принять любой из трех форматов: Rd, Ld ^ Rd, Ld, S ^ Rd, Ld, S, Ra, La

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

P.S. А вообще первоначально я хотел передавать именно векторы. Т.е. МК будет держать у себя абстрактную систему координат и будет получать векторы именно. С одной стороны - это дополнительные расчёты. Но с другой - в случае ошибки, она легко скорректируется верхним уровнем, т.к. тот получит текущие координаты бота (причём они будут действительны для реальной координатной плоскости, в которой мозг двигал робота), после чего ему не сложно будет расчитать 1-2 вектора, проехав которые мы скорректируем ошибку.
Но минус большой - это снижение потенциального количества маневров. Хотя. А кто запрещает скомбинировать оба этих подхода?