Расчет в sympy вот что-то такое даёт… Но, конечно проверить надо. (l1, l2 — длины суставов, x,y,z — координаты конечной точки, q0,q1,q2 — углы на сервоприводах)
q₀ = atan2(y, x)
_______________________________
╱ 2
╱ ⎛ ______________⎞
╱ ⎜ ╱ 2 2 2 ⎟
╱ ⎝l₁ - ╲╱ x + y + z ⎠
l₂⋅ ╱ 1 - ─────────────────────────
⎛ _________⎞ ╱ 2
⎜ ╱ 2 2 ⎟ ╲╱ l₂
q₁ = atan2⎝z, ╲╱ x + y ⎠ - ──────────────────────────────────────────
l₁
⎛ ______________⎞
⎜ ╱ 2 2 2 ⎟
⎜-l₁ + ╲╱ x + y + z ⎟
q₂ = acos⎜───────────────────────⎟
⎝ l₂ ⎠
Генерирующий скрипт:
(r — расстояние от начала координат до концевой точки, beta — угол между горизонтальной плоскостью и вектором, проведенным от начала координат до концевой точки)
#!/usr/bin/env python3
#coding: utf-8
from sympy import *
var("beta q(0:3) l1 l2 z r x y z")
eq1 = Eq(r, l1 + l2*cos(q2))
eq2 = Eq(beta, q1+l2*sin(q2)/l1)
slv = solve([eq1,eq2], [q1,q2])
slv0 = slv[0]
h = sqrt(x**2 + y**2)
pprint(Eq(q0, atan2(y,x)))
pprint(Eq(q1, slv0[0].subs({beta:atan2(z, h), r:sqrt(z**2+h**2)})))
pprint(Eq(q2, slv0[1].subs({beta:atan2(z, h), r:sqrt(z**2+h**2)})))
Вообще, я тут посчитал и у меня получаются удивительные, надо сказать, результаты.
Понятно, что кватернионное умножение быстрее, чем матричное само по себе… но… Вторая компонента портит все дело…
Вычисляем предберя производную: 2x*(x+3) + x^2 = 3*x*x + 6*x = 3*x*(x+2)
Итого: 1 сложение, 2 умножения. (и столько же, если мы хотим и значение функции тоже (Итого: 2 сложения, 4 умножения))
Проблема в том, что, если вы погоните дуальные числа через кватернионы, то каждая операция умножения (коих в кватернионном умножении 16) будет превращаться в три. Стоимость кватернионного умножения в дуальных числах — 48 аппаратных умножений, не считая сложений.
Это будет работать, но, как я пишу выше, это огроменный оверхед по производительности. Это вдвойне излишне, учитывая, что обычно в контексте задач кинематики (для которых обычно применяются кватернионы и бикватернионы)
g'(M*x) == M*g'(x) — производная трансформированного вектора равна трансформированной производной вектора (хотя, это, конечно… не всегда)…
Рискну предположить. Взятие производной с помощью дуальных чисел само по себе вычислительно избыточно, а значит, никак не может быть использовано для «быстрого» вычисления компонент кватернионной производной.
Случай кватернион + 3вектор тут не рассматривается, но если подумать, комбинация преобразований в этой форме включает довольно затратный поворот 3вектора. Надо будет посчитать на досуге.
У меня такой вопрос:
Есть ли преимущество в использовании бикватерниона перед преобразованием, описываемым кватернионом (для ориентации) и 3-вектором (для трансляции). Есть ли преимущество по скорости вычисления комбинированного перемещения?
Собственно, в таком варианте, мы опять потрошим брокера, передавая некоторые это функции шине, а некоторые навязываем нодам, а а в целом получаем похожий функционал.
Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
Мы просто берём правила и начинаем выстраивать матрицу инцендентности, последовательно пытаясь тыкать во все клетки:
2 фигуры, одно совпадение.
3 фигуры, одно совпадение (может я тут где-то ошибся...)
… И таки да, я тут ошибся. Но не суть...
3 фигуры, два совпадения
Ну и так далее. Задача решается обыкновенным перебором.
А… Ну, кстати, в статье же об этом и написано...
del
Расчет в sympy вот что-то такое даёт… Но, конечно проверить надо. (l1, l2 — длины суставов, x,y,z — координаты конечной точки, q0,q1,q2 — углы на сервоприводах)
Генерирующий скрипт:
(r — расстояние от начала координат до концевой точки, beta — угол между горизонтальной плоскостью и вектором, проведенным от начала координат до концевой точки)
Понятно, что кватернионное умножение быстрее, чем матричное само по себе… но… Вторая компонента портит все дело…
(q0*q1, r0*q1+q0*r1) — бикватернионы — 48 умножений, 40 сложений.
(q0*q1, r0+qrot(r1, q0)) — кватернион + вектор — 41 умножение, 35 сложений.
(M0*M1, r0 + M0*r1) -> 36 умножений, 27 сложений…
!!!
Оказывается, расчет в матрицах — самый быстрый… То ли я где-то накосячил в расчете, то ли… вся картина мира едет.
x->(a,1)
x^2 -> (a,1)*(a,1) -> (a*a, a*1 + a*1) -> (b, bi)
x+3 -> (a,1) + (3,0) -> (a+3, 1+0) -> (c, ci)
x^2 * (x+3) -> (b,bi)*(c,ci) -> (b*c, b*ci + c*bi) -> (d, di)
result: (d, di).imag -> di
Итого: 6 умножений, 4 сложения.
Вычисляем предберя производную: 2x*(x+3) + x^2 = 3*x*x + 6*x = 3*x*(x+2)
Итого: 1 сложение, 2 умножения. (и столько же, если мы хотим и значение функции тоже (Итого: 2 сложения, 4 умножения))
Проблема в том, что, если вы погоните дуальные числа через кватернионы, то каждая операция умножения (коих в кватернионном умножении 16) будет превращаться в три. Стоимость кватернионного умножения в дуальных числах — 48 аппаратных умножений, не считая сложений.
g'(M*x) == M*g'(x) — производная трансформированного вектора равна трансформированной производной вектора (хотя, это, конечно… не всегда)…
Если посчитать количество операций на расчет функции + производной и на расчет функции в дуальных числах, окажется, что второе вычислительно тяжелее
Надо будет почитать статью.
P.S. Если преобразование точки, то 3вектор+кватернион однозначно медленнее матрицы 3х4.
У меня такой вопрос:
Есть ли преимущество в использовании бикватерниона перед преобразованием, описываемым кватернионом (для ориентации) и 3-вектором (для трансляции). Есть ли преимущество по скорости вычисления комбинированного перемещения?
P.S. А, хотя вижу комментарий выше.
Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
П.С. в теории то все очевидно… Когда тебе уже показали и рассказали.