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

Closed
opened 2022-01-24 21:43:55 +03:00 by movefasta · 26 comments
movefasta commented 2022-01-24 21:43:55 +03:00 (Migrated from gitlab.com)

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

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

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

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

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

  • Выбор площадок поверхности по клику мыши (две (или три, если захват трехпальцевый) параллельные, противоположно направленные по нормали и одинаково направленные по ориентации пальцев захвата площадки) (Возможно, в будущем сделать автоматизированное распознавание подходящих по требованиям площадок и сохранять их автоматически)
  • Выбор координаты размещения кончика пальца, указание нормали поверхности.
  • Указание направления позиционирования главной оси захвата относительно детали
  • Указание модели захвата, параметра раскрытия захвата, угла поворота поворотной головы (при наличии)
  • Размещение "призрака" захватного устройства на детали по этим данным
  • Экспорт всей представленной информации в файл типа 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

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

unassigned @openfablab
movefasta commented 2023-02-05 00:15:24 +03:00 (Migrated from gitlab.com)

assigned to @ius.mark.alex

assigned to @ius.mark.alex
movefasta commented 2023-02-05 00:21:11 +03:00 (Migrated from gitlab.com)

changed the description

changed the description
movefasta commented 2023-02-05 00:26:20 +03:00 (Migrated from gitlab.com)

changed the description

changed the description
movefasta commented 2023-02-05 00:27:59 +03:00 (Migrated from gitlab.com)

changed the description

changed the description
movefasta commented 2023-02-05 00:31:03 +03:00 (Migrated from gitlab.com)

changed the description

changed the description
movefasta commented 2023-02-05 00:34:57 +03:00 (Migrated from gitlab.com)

changed the description

changed the description
ius.mark.alex commented 2023-02-17 15:14:47 +03:00 (Migrated from gitlab.com)

changed the description

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

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?

Думаю можно. Программирование в любом случае необходимо. Т.к. цель у нас обеспечить наибольшую автономность какую можем обеспечить. Дабы другие наши направления не застаивались в ожидании какого-либа препроцессинга, можно ввести упрощённый, основанный на уже готовых плагинах. Но этот инструмент если и вводить, то это не решение 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

mentioned in issue #35
solid-sinusoid commented 2023-02-23 23:53:54 +03:00 (Migrated from gitlab.com)

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

@movefasta я думаю что имеется в виду задача типа gpd алгоритма, который я недавно вкинул в телеграмме
movefasta commented 2023-02-24 15:52:16 +03:00 (Migrated from gitlab.com)

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

@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

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

unassigned @ius.mark.alex
movefasta commented 2023-06-18 18:39:26 +03:00 (Migrated from gitlab.com)

assigned to @ius.mark.alex

assigned to @ius.mark.alex
movefasta commented 2023-06-18 18:39:30 +03:00 (Migrated from gitlab.com)

unassigned @brothermechanic

unassigned @brothermechanic
movefasta commented 2023-06-18 18:44:27 +03:00 (Migrated from gitlab.com)

mentioned in merge request !35

mentioned in merge request !35
movefasta (Migrated from gitlab.com) closed this issue 2023-06-18 18:55:13 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: robossembler/framework#1
No description provided.