Реализовать вычисление позиции захвата для детали

movefasta commented

2022-01-24 21:43:55 +03:00

(Migrated from gitlab.com)

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

Добавляешь модель захвата (упрощённую модель grip-tool) в проект
Позиционируешь захват с помощью assembly верстака
Нажимаешь кнопку "Сгенерировать позицию захвата"
Создаётся специальный объект с параметром "PartToHandle", содержаший необходимую информацию о дистанции между пальцами и точке позиционирования захвата
В ходе экспорта модели для симулятора позиция захвата прилагается к модели в виде файла формата json

Отредактировать имеющийся скрипт:

Убрать оттуда *.brep файлы и пути к ним
Убрать лишний функционал
Исправить

Пользователю нужно обеспечить удобный интерфейс для задания разметки

Выбор площадок поверхности по клику мыши (две (или три, если захват трехпальцевый) параллельные, противоположно направленные по нормали и одинаково направленные по ориентации пальцев захвата площадки) (Возможно, в будущем сделать автоматизированное распознавание подходящих по требованиям площадок и сохранять их автоматически)
Выбор координаты размещения кончика пальца, указание нормали поверхности.
Указание направления позиционирования главной оси захвата относительно детали
Указание модели захвата, параметра раскрытия захвата, угла поворота поворотной головы (при наличии)
Размещение "призрака" захватного устройства на детали по этим данным
Экспорт всей представленной информации в файл типа json

Нужно использовать какой-то из стандартных сборочных верстаков FreeCAD для добавления позиции захвата. Механизм работы следующий: 1. Добавляешь модель захвата (упрощённую модель [grip-tool](https://gitlab.com/robossembler/arm-tools/grip-tool)) в проект 2. Позиционируешь захват с помощью assembly верстака 3. Нажимаешь кнопку "Сгенерировать позицию захвата" 4. Создаётся специальный объект с параметром "PartToHandle", содержаший необходимую информацию о дистанции между пальцами и точке позиционирования захвата 5. В ходе экспорта модели для симулятора позиция захвата прилагается к модели в виде файла формата json Отредактировать [имеющийся скрипт](https://gitlab.com/robossembler/framework/-/blob/master/GraspPose.py): 1. Убрать оттуда *.brep файлы и пути к ним 2. Убрать лишний функционал 3. Исправить Пользователю нужно обеспечить удобный интерфейс для задания разметки * Выбор площадок поверхности по клику мыши (две (или три, если захват трехпальцевый) параллельные, противоположно направленные по нормали и одинаково направленные по ориентации пальцев захвата площадки) (Возможно, в будущем сделать автоматизированное распознавание подходящих по требованиям площадок и сохранять их автоматически) * Выбор координаты размещения кончика пальца, указание нормали поверхности. * Указание направления позиционирования главной оси захвата относительно детали * Указание модели захвата, параметра раскрытия захвата, угла поворота поворотной головы (при наличии) * Размещение "призрака" захватного устройства на детали по этим данным * Экспорт всей представленной информации в файл типа json

movefasta commented

2022-01-24 21:43:55 +03:00

(Migrated from gitlab.com)

assigned to @openfablab

solid-sinusoid commented

2022-01-24 21:45:15 +03:00

(Migrated from gitlab.com)

http://docs.ros.org/en/noetic/api/geometry_msgs/html/msg/Pose.html

Позиция захвата точка с указанием углов поворота

one: [0.01, 0.01, 0.6, 0.0 , 0.0 , 0.0, 1.0]
#     (x     y     z)  (x     y     z    w)

Для задания растояния между пальцами необходима константа просто

width_fingers: 0.003
# Максимальное растояние между пальцами = 0.006
# Минимальное = 0

По стандарту yaml всё это конфигурируется

body_012301:
    one: [0.01, 0.01, 0.6, 0.0 , 0.0 , 0.0, 1.0]
    with_fingers: 0.002123
# И остальные параметры к детали, можно обсудить

Также если реализовывать запись на сервер параметров ROS2 необходимо иметь следующие изменения

body_012301:
    ros__parameters:
        one: [0.01, 0.01, 0.6, 0.0 , 0.0 , 0.0, 1.0]
        with_fingers: 0.002123

Это требут проверки, удобней ли так будет или нет

http://docs.ros.org/en/noetic/api/geometry_msgs/html/msg/Pose.html Позиция захвата точка с указанием углов поворота ```yaml one: [0.01, 0.01, 0.6, 0.0 , 0.0 , 0.0, 1.0] # (x y z) (x y z w) ``` Для задания растояния между пальцами необходима константа просто ```yaml width_fingers: 0.003 # Максимальное растояние между пальцами = 0.006 # Минимальное = 0 ``` По стандарту yaml всё это конфигурируется ```yaml body_012301: one: [0.01, 0.01, 0.6, 0.0 , 0.0 , 0.0, 1.0] with_fingers: 0.002123 # И остальные параметры к детали, можно обсудить ``` Также если реализовывать запись на сервер параметров ROS2 необходимо иметь следующие изменения ```yaml body_012301: ros__parameters: one: [0.01, 0.01, 0.6, 0.0 , 0.0 , 0.0, 1.0] with_fingers: 0.002123 ``` Это требут проверки, удобней ли так будет или нет

movefasta commented

2022-03-24 10:13:53 +03:00

(Migrated from gitlab.com)

В настоящий момент позиция определяется автоматически, но не корректно. Приходится подправлять

movefasta commented

2023-01-13 15:12:19 +03:00

(Migrated from gitlab.com)

unassigned @openfablab

movefasta commented

2023-02-05 00:15:24 +03:00

(Migrated from gitlab.com)

assigned to @ius.mark.alex

movefasta commented

2023-02-05 00:21:11 +03:00

(Migrated from gitlab.com)

changed the description

movefasta commented

2023-02-05 00:26:20 +03:00

(Migrated from gitlab.com)

changed the description

movefasta commented

2023-02-05 00:27:59 +03:00

(Migrated from gitlab.com)

changed the description

movefasta commented

2023-02-05 00:31:03 +03:00

(Migrated from gitlab.com)

changed the description

movefasta commented

2023-02-05 00:34:57 +03:00

(Migrated from gitlab.com)

changed the description

ius.mark.alex commented

2023-02-17 15:14:47 +03:00

(Migrated from gitlab.com)

changed the description

movefasta commented

2023-02-21 21:07:28 +03:00

(Migrated from gitlab.com)

К вопросу задания позиции захвата.

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

Мне нравится идея использовать какой-то существующий (желательно используемый конструкторами) верстак, потому что задание относительных позиций - наважно чего - деталей, подсборок, захватного устройства, стола или кондуктора - это всё частные случаи сборок. Можем назвать их для удобства временными сборками. Временные сборки - это подсборки с использованием специальных приспособлений, которые не войдут в итоговое изделие. Однако, у них есть ряд свойств - они обеспечивают процесс сборки. И у них будут определённые свойства - ведь часто эти вспомогательные элементы(типа захватного устройства) являются подвижными. Даже элементарное размещение двух кубиков на столе - это тоже временная сборка двух кубиков и стола - ведь два кубика не могут просто висеть в пространстве. Эти временные подсборки должны быть как-то заданы. Как их задать? Самый простейший вариант - просто задать вспомогательный элемент временной сборки - добавить в сборку стол, гриппер, кондуктор. Но тогда у нас в значительной степени сокращается свобода манёвра - позиции кубиков заданы жёстко, хотя мы понимаем, что поставить их можно на любое плоское место - лишь бы не свалились. По идее, для обеспечения гибкости робот должен понимать, что два кубика, лежащих на столе, и два кубика, лежащих на торце цилиндра, это оба варианта валидной сборки. То есть нужно задавать не напрямую оснастку, а какие-то другие параметры - например, свойства сопряжения с учётом обеспечения стабильности положения. Чтобы у нас роботы могли использовать свои грипперы или какие-то другие свои части для создания ситуативных временных подсборок. Как это делают фрактальные тиски, но более умные.

К вопросу задания позиции захвата. С одной стороны привязка к конкретной модели гриппера надёжна, с другой стороны несколько сужает пространство выбора. Ведь, задачу можно решать разными методами. Мне нравится идея использовать какой-то существующий (желательно используемый конструкторами) верстак, потому что задание относительных позиций - наважно чего - деталей, подсборок, захватного устройства, стола или кондуктора - это всё частные случаи сборок. Можем назвать их для удобства временными сборками. Временные сборки - это подсборки с использованием специальных приспособлений, которые не войдут в итоговое изделие. Однако, у них есть ряд свойств - они обеспечивают процесс сборки. И у них будут определённые свойства - ведь часто эти вспомогательные элементы(типа захватного устройства) являются подвижными. Даже элементарное размещение двух кубиков на столе - это тоже временная сборка двух кубиков и стола - ведь два кубика не могут просто висеть в пространстве. Эти временные подсборки должны быть как-то заданы. Как их задать? Самый простейший вариант - просто задать вспомогательный элемент временной сборки - добавить в сборку стол, гриппер, кондуктор. Но тогда у нас в значительной степени сокращается свобода манёвра - позиции кубиков заданы жёстко, хотя мы понимаем, что поставить их можно на любое плоское место - лишь бы не свалились. По идее, для обеспечения гибкости робот должен понимать, что два кубика, лежащих на столе, и два кубика, лежащих на торце цилиндра, это оба варианта валидной сборки. То есть нужно задавать не напрямую оснастку, а какие-то другие параметры - например, свойства сопряжения с учётом обеспечения стабильности положения. Чтобы у нас роботы могли использовать свои грипперы или какие-то другие свои части для создания ситуативных временных подсборок. Как это делают фрактальные тиски, но более умные.

movefasta commented

2023-02-21 21:32:24 +03:00

(Migrated from gitlab.com)

assigned to @brothermechanic

brothermechanic commented

2023-02-23 19:03:12 +03:00

(Migrated from gitlab.com)

@movefasta @solid-sinusoid
как насчет обойтись для начала вообще без программирования, а на имеющихся плагинах как assembly4, Frames, и пр. "протоптать" тех процесс?

@movefasta @solid-sinusoid как насчет обойтись для начала вообще без программирования, а на имеющихся плагинах как assembly4, Frames, и пр. "протоптать" тех процесс?

solid-sinusoid commented

2023-02-23 20:58:25 +03:00

(Migrated from gitlab.com)

Думаю можно. Программирование в любом случае необходимо. Т.к. цель у нас обеспечить наибольшую автономность какую можем обеспечить. Дабы другие наши направления не застаивались в ожидании какого-либа препроцессинга, можно ввести упрощённый, основанный на уже готовых плагинах. Но этот инструмент если и вводить, то это не решение issue, так что, следует ввести генерацию захватных позиций так быстро как это возможно, потом заменяя уже своим разработанным модулем. @brothermechanic считай готовый плагин просто как временную затычку которые следует пока удерживать, пока реальный инструмент не будет готов. Моё мнение. Что считает @movefasta?

movefasta commented

2023-02-23 21:02:15 +03:00

(Migrated from gitlab.com)

Что подразумевается под программированием? Программирование робота?

Сейчас задачу задания последовательности сборки и генерации PDDL на базе assembly4 реализуют @IDONTSUDO и @ius.mark.alex в рамках #33. Было бы здорово тебе подключиться к процессу и рассмотреть assembly4 для задания позиции захвата. Так или иначе, останется необходимость подгрузить SDF/URDF-модель захвата и любой другой оснастки, чтобы однозначно ассоциировать позицию захвата с конкретной моделью захвата/оснастки, а также с спецификацией задачи в PDDL. Думаю, что логично именно тебе это реализовывать.

Что подразумевается под программированием? Программирование робота? Сейчас задачу задания последовательности сборки и генерации PDDL на базе assembly4 реализуют @IDONTSUDO и @ius.mark.alex в рамках #33. Было бы здорово тебе подключиться к процессу и рассмотреть assembly4 для задания позиции захвата. Так или иначе, останется необходимость подгрузить SDF/URDF-модель захвата и любой другой оснастки, чтобы однозначно ассоциировать позицию захвата с конкретной моделью захвата/оснастки, а также с спецификацией задачи в PDDL. Думаю, что логично именно тебе это реализовывать.

movefasta commented

2023-02-23 21:11:08 +03:00

(Migrated from gitlab.com)

mentioned in issue #35

solid-sinusoid commented

2023-02-23 23:53:54 +03:00

(Migrated from gitlab.com)

@movefasta я думаю что имеется в виду задача типа gpd алгоритма, который я недавно вкинул в телеграмме

movefasta commented

2023-02-24 15:52:16 +03:00

(Migrated from gitlab.com)

@solid-sinusoid в нашем сценарии позиции захвата расставлены инженером в соответствии с захватным приспособлением. Насколько я знаю, GPD может сгенерировать большое количество вариантов позиций, но остаются вопросы: 1. Будет ли среди множества позиций наша, заранее предусмотренная позиция? 2. Если будет, то каким образом алгоритм предпочтет именно её?

solid-sinusoid commented

2023-02-24 16:12:55 +03:00

(Migrated from gitlab.com)

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

Ограничиваем пространство выбора захватных позиций, оставляем лишь свободное от контакта с итоговой подсборкой
Даём пользователю выбор между автоматизированной генерацией и ручной
Если пользователь выбрал автоматизированную генерацию, тогда пользователю предлагается результирующая позиция, которую он может немного подправить, если заметил неточности (при желании)
Сделать интерфейс выбора или замены захватной позиции в сферических координатах вокруг детали, с маркером для перемещения самого захватного устройства в нужную позицию

@movefasta здесь нужны некоторые исследования и конкретно качество сгенерированных позиций и будет предметом исследования. Естественно всё зависит от способа фильтрации позиций захвата, а как это будет производиться, будет уже от конкретной реализации. Возможно стоит учесть, что пользователь инженер не захочет расставлять все позиции самостоятельно, а захочет сделать это автоматически. Тут нам и пригождаются подобные алгоритмы. После выполнения которых, оставить возможность лишь подправить позиции. Так или иначе, захватные позиции должны будут располагаться в тех областях, которые будут находиться вне области контакта с подсборкой, куда эта деталь вставляется. Тогда есть смысл банально ограничивать пространство выбираемое пользователем инженером, дабы инженер не выстрелил себе в ногу выставляя позиции захвата. Вы имеете в виду сценарий реализации сборки робота с подготовленными контактными площадками. Это решение стоило усилий на стадии проектирования, но мы все знаем, что не каждое собираемое устройство будет оснащено такими элементами. В таком случае следующее будет разумно: - Ограничиваем пространство выбора захватных позиций, оставляем лишь свободное от контакта с итоговой подсборкой - Даём пользователю выбор между автоматизированной генерацией и ручной - Если пользователь выбрал автоматизированную генерацию, тогда пользователю предлагается результирующая позиция, которую он может немного подправить, если заметил неточности (при желании) - Сделать интерфейс выбора или замены захватной позиции в сферических координатах вокруг детали, с маркером для перемещения самого захватного устройства в нужную позицию

movefasta commented

2023-02-25 18:13:20 +03:00

(Migrated from gitlab.com)

mentioned in issue #39

movefasta commented

2023-02-25 18:16:59 +03:00

(Migrated from gitlab.com)

@solid-sinusoid Да, нужно провести исследование по методам генерации захватных позиций. Создал задачу #39 - прошу дополнить описание, если требуется.

Даём пользователю выбор между автоматизированной генерацией и ручной

"Либо" - не очень подходящий термин. Оба метода могут взаимно дополнять друг друга.

@solid-sinusoid Да, нужно провести исследование по методам генерации захватных позиций. Создал задачу #39 - прошу дополнить описание, если требуется. > Даём пользователю выбор между автоматизированной генерацией и ручной "Либо" - не очень подходящий термин. Оба метода могут взаимно дополнять друг друга.

movefasta commented

2023-02-27 19:59:55 +03:00

(Migrated from gitlab.com)

unassigned @ius.mark.alex

movefasta commented

2023-06-18 18:39:26 +03:00

(Migrated from gitlab.com)

assigned to @ius.mark.alex

movefasta commented

2023-06-18 18:39:30 +03:00

(Migrated from gitlab.com)

unassigned @brothermechanic