That looks excellent. I'd love to try out my IK engine in MRL to see if we could compute the proper angles.
The general approach is that we define the transformations between the base reference frame and the frame for the end effector (hand)
The implementation that I did in MRL uses something called the pseudo-inverse of the jacobian. At the paris maker faire, I had a conversation about another approach called the dual quaternion. It seems that there are some "divide by zero" hazards with my pseudo-inverse approach, but we probably won't really come across those for this purpose.
I'd like to add a new method to the InMoovArm service called "moveToPoint(x,y,z)" that will produce the proper joint angles to move the hand to that point in space. If we see that the basic X,Y,Z point is reached properly, I'll extend it to also support moveToPoint(x,y,z,rx,ry,rz) where we have the point in space defined by x,y,z and also the orientation of the palm of the hand as a vector defined with the rotation about the x,y,and z axis respectively. I'll see about getting this integrated ... I can also see about working up a python based example to show how to use it
Looks GREAT! I have a small unit test that creates something similar to the inmoov arm (measurements are not accurate yet) Here's a link to the code that models the arm:
Yes IK is the way to go ! I like kwatters idea about the moveToPoint(x,y,z). Just thought I would want a end-normal .. not just a point. Because, the first thing I thought of is I want the "palm" of the hand against the bottle. Having a point in the palm is not enough.
I'm still grappling with the concept of "moving" in Blender vs. "positioning"
I know there's a Physics engine in Blender and it would know about inertia, mass, possibly friction, etc.. and deal with "moving" .. aren't we curently doing "positioning" ?
Elves give standing ovation..
There asking me with drool - "When can we get the file" :D
Inverse Kinematcis In MRL
That looks excellent. I'd love to try out my IK engine in MRL to see if we could compute the proper angles.
The general approach is that we define the transformations between the base reference frame and the frame for the end effector (hand)
The implementation that I did in MRL uses something called the pseudo-inverse of the jacobian. At the paris maker faire, I had a conversation about another approach called the dual quaternion. It seems that there are some "divide by zero" hazards with my pseudo-inverse approach, but we probably won't really come across those for this purpose.
I'd like to add a new method to the InMoovArm service called "moveToPoint(x,y,z)" that will produce the proper joint angles to move the hand to that point in space. If we see that the basic X,Y,Z point is reached properly, I'll extend it to also support moveToPoint(x,y,z,rx,ry,rz) where we have the point in space defined by x,y,z and also the orientation of the palm of the hand as a vector defined with the rotation about the x,y,and z axis respectively. I'll see about getting this integrated ... I can also see about working up a python based example to show how to use it
Looks GREAT! I have a small unit test that creates something similar to the inmoov arm (measurements are not accurate yet) Here's a link to the code that models the arm:
https://github.com/MyRobotLab/myrobotlab/blob/master/test/org/myrobotlab/kinematics/DHRobotArmTest.java#L91
InMoov Clears the Table !!
Amazing work Gareth ! :D
Yes IK is the way to go ! I like kwatters idea about the moveToPoint(x,y,z). Just thought I would want a end-normal .. not just a point. Because, the first thing I thought of is I want the "palm" of the hand against the bottle. Having a point in the palm is not enough.
I'm still grappling with the concept of "moving" in Blender vs. "positioning"
I know there's a Physics engine in Blender and it would know about inertia, mass, possibly friction, etc.. and deal with "moving" .. aren't we curently doing "positioning" ?
Elves give standing ovation..
There asking me with drool - "When can we get the file" :D