roboforum.ru

Здравствуйте Господа
В некотором смысле топик ушел в некоторое отвлеченное обсуждение
DEAD предлагает, как я понял, сформулировать общую концепцию визуального представления, с помощью специальной программы, абстрактного механизма состоящего из рычагов, с различными вариантами скрепления друг с другом: - подвижный конец, жесткое закрепление, и прочее , поворотных механизмов с некоторыми деталейадаваемыми ограничениями ( угол поворота например, усилие и возможно другие....)и вариантами крепления к рычагам.
В рамках использования типовых контроллеров, типовых механизмов ( см топики о лазерной резке по разработке универсальных "железяках", необходима программа по "оживлению"(программированию) поведения собранного механизма
Однажды в жизни, я участвовал в разработке и внедрению универсального робота который программировался по движениям ( это манипулятор): - повернись, вытяни руку, разожми захват, и прочее... он запоминал это и можно пустить все дальше по шагам...
Была написана программа которая может посылать правляющие воздействия по шагам, запоминает их, и может повторять их многократно, с помощью такой программы чрезвычайно трудно например запрограммировать шаг двухнога, так как необходимо практически одновременно задавать воздействия 8-10 сервоприводами
В настоящее время я обдумываю написание программы в которой будет реализован такой алгоритм "моделирования"
пример подобной прогарммы, все уже изобретено до нас, к своему удовольствию опубликовал Michael-K_ на вкладке 4 этого поста.
предлагаю обсудить собственно сам интерфейс этой программы - ее графический образ, ограниченный список деталей из которых возможно будет собрать механизм, способ описания ограничей и прочее...
На чем будет написана программа, какие алгоритмы будет использовать дело второе. Удобнее использовать принцип: -
" я думаю программа должна выглядеть вот так..." взял из библиотеку серву, прицепил к нему рычаг, со стороны серв жеско, друной конец шарнир. Взял другую серву .... . повернул одну серву на угол, посмотрел - многовато будет ....( это пример)
loox

Ну я про визуальное представление не имел в виду, хотя-бы в виде структур данных. Надо в первую очередь взять и посмотреть что уже сделано - тут 3 библиотеки выложил уже Angel71: viewtopic.php?p=138960#p138960

Вы правы, без сомнения ...
loox

Тут, имхо, несколько больших вопросов по существу...

1. Что мы хотим получить...
Алгоритм, который выводит ступню в заданную позицию в координатах робота.
Правильно или нет? Или не только его?

2. Что мы должны для этого описать...
Тут масса вариантов - от простого к сложному:
- Кинематическую модель ноги (взаимное расположение осей, длины рычагов).
- Собственные габаритные ограничения (углы серв, всякие мешающие торчащие "коленки" и т.п.)
- Взаимные габаритные ограничения (чтобы ноги не мешали друг-другу)
(иноходец бежит быстрее, потому что шаг шире - ноги не мешают друг-другу)
- Физические ограничения (углы, усилия, массы моменты, скорости серв)
(например, со шпагата можно и не встать - усилия на таком длинном рычаге не хватит)
И так далее... начиная от статической устойчивости (что в принципе неплохо бы),
...кончая динамикой бега по пересеченной местности
в режиме управляемого заноса ) (что, пожалуй, перебор)

3. Какие функции мы должны выдать "наверх"...
set_leg_position, и пара флажков (коллбэков) типа DONE и ERROR?
или еще и модель и ее текущие параметры
(например чтобы верхний уровень мог планировать действия,
или, скажем, вычислить центр тяжести и т.д. )

В общем, я бы задумался сначала о том, чего же именно хочется...
Что оно должно уметь?

Насколько я понимаю массово используется
простой вариант - это только кинематическая иодель,
и ВРУЧНУЮ вколоченные таблицы действий в секвенсор.
При этом ограничения туда жестко вбиваются с огромными запасами.

Менее массово - вариант с датчиками...
Тут, я боюсь, что унифицированный подход не прокатит.

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

А всякие сложные модели... имхо, только для 3D-анимаций годятся...


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

Да и "управление шагающими платформами" скорее подразумевает управление
роботом целиком, а не каждой ногой в отдельности.

Представьте, что у вас есть пульт управления...
Наверное, можно сделать на нем 18 потенциометров для управления
координатами каждой ноги...
Только вот... удобно ли это?

Секвенсор - это по сути дела пульт управления.
Наверное, для управления роботом нужно принять иерархическую модель управления.
Нижний уровень управляет отделными сервами, более высокий - отдельным сочленением. И т.д. вплоть до всего робота. Тогда команды управления должны адресоваться к соотв. уровню и иметь аналогичный уровень абстрагирования.
Это как иерархия обычных языков программирования: машинные коды -> ассемблер -> С и т.д.
Но, скорее всего нельзя будет управлять только одним уровнем, а как в ЯП делать вставки из разных уровней. Например, когда дадим комаду переместиться всему роботу из точки А в точку Б и когда он в нее попадет, то двинуть правым манипулятором вправо, а затем с таким то усилием захвата взять банку пива, то тут видно, что в цепочке команд есть разноуровневые.
При этом нужно учитывать варианты - робот без датчиков и с датчиками обратной связи.
Из известных языков управления роботами: GRL - Generic Robot Language, RAPS - Reactive Action Plan System. Есть и другие языки.
viewtopic.php?f=61&t=6800&start=375#p134085
Там я писал про трехзвенную архитектуру роботов. Правильнее было бы начать с самого нижнего уровня - реактивного.

Michael_K писал(а):1. Что мы хотим получить...
Алгоритм, который выводит ступню в заданную позицию в координатах робота.
Правильно или нет? Или не только его?

Далеко "не только его"
Как минимум - софт для ведения этой ступни по какой-то траектории.

Остальное чуть позже напишу, дела

Добавлено спустя 14 минут 34 секунды:

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

А всякие сложные модели... имхо, только для 3D-анимаций годятся...

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

Виктор Казаринов, секвенсер по сути это и есть "нижний уровень", т.е. непосредственно управлялка сервами. он уже давно есть, с орфой или без неважно.
насколько я понимаю, здесь планируется обсуждение статики (вес, центр тяжести, равновесие,...), прямой и обратной кинематики, динамики движения как в целом, так и отдельных элементов (суставов, конечностей,...),...
GRL, RAPS,... имхо, муть какая-то очередной анти-паттерн.
Michael_K, при построении модели главное принцип достаточности. пока мне видится, что будет достаточно представлять всё как набор отрезков в пространстве, по сути просто описать скелет. более точная 3д модель это неплохо, но рано.

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

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

кому как, а я пока секвенсором буду считать только собственно управлялки сервами, т.е. ssc-32. дабы сразу же не запутатся в терминах.

2Angel71: Поздно, уже запутались, SSC-32 это сервоконтроллер

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

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

Надо бы накидать несколько вариантов, как это всё может быть устроено.
Самый простой конечно вариант - есть программа в которой заложена серия положений серв, и эта программа между ними плавно переводит сервы. Это секвенсор от Lynxmotion вроде делает.

Более сложная схема - закладывать положения не серв, а конечностей, это позволит, например, держать у шестинога туловище в ровном положении при ходьбе по ровной поверхности. Еще более сложная - задавать сложные траектории, а не прямые. Это с точки зрения управления по предварительно заложенным шаблонам.

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

Виктор Казаринов писал(а):Кроме того, неплохо бы сразу заложить в него систему плагинов, например, для разных видов получения управляющих команд (прямого ввода, от 3D модели и т.д.)

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

не не не, я пока еще мыслями тут: "SSC-32 General Purpose Sequencer" (http://lynxmotion.com/images/html/build137.htm) с его 12ти сервовым встроенным.

Я считаю что

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

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

Michael_K писал(а):стоит заметить, что построение точной модели на самом деле неоправдано,
так как...

Не понял логики. Есть модели для построения плана движений, есть модели...

Я имел в виду "физическую модель", которая описывает механику, статику, динамику...
(длины, углы, массы, моменты, размеры, скорости, усилия итд итп)

Чтобы мысль было понятнее:
Например, в условного "БигДога" можно было бы ввести его физические параметры
так, чтобы он всегда располагал проекцию своего ЦТ внутри многоугольника стоящих ног...
Для этого нужно было бы задать массы и центры тяжести всех движущихся частей
и жестко управлять их положением (статику для простоты рассмотрим).

В таком случае, он, смог бы ходить по плоскости и без датчиков. Но...
Если мы повесим на него рюкзак, или нога встанет на кочку,
или случатся другие "внешние воздействия", он будет падать...

А вот если он, скажем, чувствует ногами, куда направлена "реакция опоры",
и какая она по величине, то параметры его физ модели можно и не вводить,
а саму физ модель сделать существенно проще -
он может просто ставить ногу так, чтобы равномерно распределить вес
и выправить направление силы тяжести...

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

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