fabrik chain implementation

[ahundt]

I'm interested in using the fabrik chain implementation, and the version in devel looks easier to use. Should that work or is it still expected to change substantially?

[wolftype]

hi -- devel branch is pretty active right now with major revisions, but vsr_chain is fairly stable. actually your question led me to find a small bug in the calcJoints() method, I also added an examples/xFabrikChain.cpp for reference on how to use the fabrik() solver. let me know if/how it works for you!

[ahundt]

Thanks! I'll give it a try.

I had to hack things a bit to get stuff to compile. I wanted to see some of the stuff in scratch because it looks like there are some good examples of IK in there. I manually set some of the paths and compiled GLV, but it seems to be a bit of a mess. :-)

[ahundt]

I made a gist with a cmake patch and errors for the versor scratch folder

[ahundt]

I'm also interested in using the new model constraints published for FABRIK with vsr_chain. Any chance those are present or could be added relatively easily?

• Extending FABRIK with model constraints paper
• Overview of IK methods, including some FABRIK model constraints details
• FABRIK IK algorithm creator's site.

In my case I just have 7dof revolute joints and need to set joint limits.

There is also an interesting thread related to constraints, and another on math.stackexchange

[wolftype]

fyi right now what i use to compile projects in scratch is

./run.sh scratch/projects/…../xProjectName.cpp

and optionally add “configure” to the end to force cmake to add it to the targets list if it is a new project

./run.sh scratch/projects/…../xProjectName.cpp configure

note that not all projects in scratch currently compile

On Jul 20, 2015, at 10:19 PM, Andrew Hundt [email protected] wrote:

Thanks! I'll give it a try.

I had to hack things a bit to get stuff to compile. I wanted to see some of the stuff in scratch because it looks like there are some good examples of IK in there. I manually set some of the paths and compiled GLV, but it seems to be a bit of a mess. :-)

—
Reply to this email directly or view it on GitHub #4 (comment).

[wolftype]

thanks for these newer references, i had not seen them but will look over them . . .

happy to help get something going, if you find a particular algorithm you want to implement.

On Jul 20, 2015, at 11:26 PM, Andrew Hundt [email protected] wrote:

I'm also interested in using the new model constraints published for FABRIK with vsr_chain https://github.com/wolftype/versor/blob/master/vsr/vsr_chain.h. Any chance those are present or could be added relatively easily?

Extending FABRIK with model constraints http://onlinelibrary.wiley.com/doi/10.1002/cav.1630/full paper
Overview of IK methods, including some FABRIK model constraints details http://www.andreasaristidou.com/publications/CUEDF-INFENG,%20TR-632.pdf
FABRIK IK algorithm creator's site http://www.andreasaristidou.com/FABRIK.html.
—
Reply to this email directly or view it on GitHub #4 (comment).

[ahundt]

The two constraints I care about are very simple: Revolute joints and joint limits. Essentially, each joint on the arm I use is a 7 rotating joint arm, and it only has a range of +/- theta from the center which varies for each joint.

I think the revolute joints are already implemented for devel, do you think the joint limits could be added easily?

[wolftype]

Traveling a bit at the moment (to the AGACSE conference!) and have not had a chance to look at the extended technique,
but I have experimented with constraining points during fabrik solver to circles, rather than spheres, which equates to
constraining the axes of rotation (or to constraining to two distances at once).

Constraining the angles would then be a matter of clamping the thetas of each to a lower and higher bound, I suppose.

Currently the ik fabrik solver in vsr_chain just constrains to spherical distances (so, ball joints), but the Constraint class in vsr_rigid.h shows some
of the ideas behind forming other constraints (between two points for instance).

I haven’t tested below, but i think the forward rotation constraint would look something like this:

1 - get location of point closest to chain[i].cxy();
2 - intersect line through that point with sphere surrounding chain[i].cxy();

Circle circle = chain[i].cxy(); /// circle of rotation
Sphere sphere = chain[i].bound(); /// sphere of rotation

Point pa = chain[i].pos();
Point pb = chain[i+1].pos();

/// Note: I would encapsulate the following into a method which takes a circle and a point p, and returns a point on the circle closest to p.
/// probably put it in Constrain::PointToCircle( p, circle)

auto cen = round::location( tangent::at( circle, p ) ); /// point on same plane as circle
auto line = pa ^ cen ^ Infinity(1); ///line through center of circle and p
auto meet = (sphere^line.dual()).dual(); /// meet of line and sphere
auto res = round::split( meet ,true); ///point on circle closest to p

then it is a matter of taking the result and limiting the rotation of the joint.

I can try this out if I get a moment….

On Jul 22, 2015, at 4:03 AM, Andrew Hundt [email protected] wrote:

The two constraints I care about are very simple: Revolute joints and joint limits. Essentially, each joint on the arm I use is a 7 rotating joint arm, and it only has a range of +/- theta from the center which varies for each joint.

I think the revolute joints are already implemented for devel, do you think the joint limits could be added easily?

—
Reply to this email directly or view it on GitHub #4 (comment).

[wolftype]

ok there were a few bugs in that of course, but i pushed a working

Constrain::PointToCircle( const Point& p, const Circle& c );

to vsr_rigid.h which calculates the point on circle c closest to p.

examples/xPointToCircle.cpp shows this particular constraint in action.

it is a little easier than i suggested, we can project the point to the plane of c,
and then interesect the line through that projected point and the center
of c with the sphere surround of c. perhaps there is an even simpler way.

this constrains a point to a circle . . . limiting its angle is then the next step
with a dot product. give a bit of time to get that into a working kinematic example…

pc

On Jul 24, 2015, at 1:20 AM, wolftype [email protected] wrote:

auto cen = round::location( tangent::at( circle, p ) ); /// point on same plane as circle
auto line = pa ^ cen ^ Infinity(1); ///line through center of circle and p
auto meet = (sphere^line.dual()).dual(); /// meet of line and sphere
auto res = round::split( meet ,true); ///point on circle closest to p

[ahundt]

awesome! Also, enjoy the conference it sounds super interesting.

[ahundt]

Any chance you could explain joint angle limits? I'm eager to try this out.

[wolftype]

I'll try to take a look at this this week - ;)

On Aug 8, 2015, at 2:02 AM, Andrew Hundt [email protected] wrote:

Any chance you could explain joint angle limits? I'm eager to try this out.

—
Reply to this email directly or view it on GitHub.

[ahundt]

cool thanks!

[wolftype]

I’ve managed to make a constrainedFabrik() method in vsr_chain
which restricts inverse kinematics movement to rotations in the xy plane.

see examples/xConstrainedFabrik.cpp

this was quite a difficult challenge, and it took me a little while, but now I have
another section for my PhD :)

note that I have not restricted the angles, just the rotation plane. restricting the angles
is a milestone for another time...

On Aug 10, 2015, at 5:47 PM, Andrew Hundt [email protected] wrote:

cool thanks!

—
Reply to this email directly or view it on GitHub #4 (comment).

[ahundt]

Wow, fantastic! Thank you!

I've just started grad school classes up again so time is a bit dear at the moment, but I have this in my project issue tracker and as soon as I have the chance I will try it, even if the angles aren't yet restricted.

When you say it is restricted to the x-y plane, do you mean a local x-y plane for each joint, or a single global x-y plane?

[ahundt]

I took a look at the code and ran the demo example, it is very impressive! By manually mousing around I can't get it to exceed ~20% cpu even if I try to maximize how often I hit singularities.

You mentioned some of this might be a section in your PhD, have you perhaps written anything up about it I could read?

Also, do you know any great resources for someone just starting to learn cga? More advanced references are useful too, I just might not get much out of them yet. I'm more familiar with linear algebra techniques for this sort of thing and I have very basic familiarity with quaternions and dual quaternions.

Actually, I just started reading the relevant wikipedia page and it seems versor is just another name for a unit quaternion? Ah, but it seems there are a couple of underlying concepts that can be used to generalize many other concepts. Well, to avoid writing a running commentary of everything I read I'll just say this looks very interesting and I hope to learn some more.

I've also been thinking through what I need to be able to make use of this constrained fabrik implementation myself. I'll just enumerate a few things below. Don't worry, I understand if implementation is up to me. However, I would appreciate any thoughts, suggestions, or plans/designs that have occurred to you.

Minimal useful implementation:

• Fixed base
• Revolute joint contraints
• Joint limits
• Ability to specify target end effector pose with position and orientation (dual quaternion, or xyzrpy, or cga equivalent)
• prevent motion where self intersection of links occurs

More complete implementation:

• time component
• derivation of velocity, acceleration, torque, and relevant constraints
• conversion between cga and linear algebra representations
• jacobian, hessian
• prevent volume self intersection (would likely make more sense to use a simulation library instead of purely using something like versor?)
• constrained optimization wrt cga?

I don't know if I'll be able to fully pursue this, but at least writing some thoughts out out felt like an interesting exercise. Hope you don't mind me filling up your issue page. :-)

[wolftype]

Thanks for your comments, Andrew — since I am not a roboticist, knowing what
is needed for a complete (and minimal useful) implementation is quite helpful to me.

What else is the issue tracker for if not for asking questions! Though I suppose
this should be considered more of a milestone than an issue ;)

It seems a minimal useful implementation is within reach with another week's work — unfortunately
that won’t happen until after December 11th.

Once that is done, it would be fun to work together on satisfying a more complete implementation.
I tend to try to do everything in GA, so that would mean doing the volume intersection detection that way
as well.

Since it is still in progress, send me an email at wolftype@gmail and I will send you
the current chapter on kinematics with CGA. Some articles on the motor algebra
by Eduardo Bayro-Corrochano are what I would read first. I can send those along as well.

By far the best introduction for me was Leo Dorst’s textbook “Geometric Algebra for Computer Science”
There are some kinematics in there as well.

Dietmar Hildenbrand wrote up some nice descriptions of
how to reason with geometric constraints in a Eurographics 2004 paper I believe.

-P

On Nov 3, 2015, at 2:08 PM, Andrew Hundt [email protected] wrote:

I took a look at the code and ran the demo example, it is very impressive! By manually mousing around I can't get it to exceed ~20% cpu even if I try to maximize how often I hit singularities.

You mentioned some of this might be a section in your PhD, have you perhaps written anything up about it I could read?

Also, do you know any great resources for someone just starting to learn cga? More advanced references are useful too, I just might not get much out of them yet. I'm more familiar with linear algebra techniques for this sort of thing and I have very basic familiarity with quaternions and dual quaternions.

Actually, I just started reading the relevant wikipedia page and it seems versor is just another name for a unit quaternion? Ah, but it seems there are a couple of underlying concepts that can be used to generalize many other concepts. Well, to avoid writing a running commentary of everything I read I'll just say this looks very interesting and I hope to learn some more.

I've also been thinking through what I need to be able to make use of this constrained fabrik implementation myself. I'll just enumerate a few things below. Don't worry, I understand if implementation is up to me. However, I would appreciate any thoughts, suggestions, or plans/designs that have occurred to you.

Minimal useful implementation:

Fixed base
Revolute joint contraints
Joint limits
Ability to specify target end effector pose with position and orientation (dual quaternion, or xyzrpy, or cga equivalent)
prevent motion where self intersection of links occurs
More complete implementation:

time component
derivation of velocity, acceleration, torque, and relevant constraints
conversion between cga and linear algebra representations
jacobian, hessian
prevent volume self intersection (would likely make more sense to use a simulation library instead of purely using something like versor?)
constrained optimization wrt cga?
I don't know if I'll be able to fully pursue this, but at least writing some thoughts out out felt like an interesting exercise. Hope you don't mind me filling up your issue page. :-)

—
Reply to this email directly or view it on GitHub #4 (comment).