Open severin-lemaignan opened 11 years ago
Minutes of a talk with [mysterious participant] on the #blendercoders IRC channel:
<skadge_> Hello there. Someone for a qestion related the IK solvers <-> rigid body constraints
<skadge_> ?
<kaito> skadge_: to my knowledge is IK only for armatures
<skadge_> kaito: our problem (the MORSE simulator team) is that rigid body constraints would be nice to model many robotic configuration.
<skadge_> But IK solvers are really important to us as well
<skadge_> so I was wondering if both world could not somehow merge
<skadge_> (our issues with armatures are: pure translations are not possible, only 'streching' which also scales the bone ; we sometimes have 2 DoF at one single point, which is problematic since bones can not have zero-lenght)
<kaito> skadge_: to my knowledge that's what ITASC solver is doing
<kaito> skadge_: you know the robotics list? http://lists.blender.org/mailman/listinfo/robotics
<skadge_> kaito: I've created it ;-)
<kaito> ok :)
<skadge_> kaito: maybe I missed something here, but ITASC takes a 'regular' Blender armature, so the limitations I mentioneed above apply here
<kaito> bones can translate too, in many ways...
<skadge_> kaito: (btw I'm one of the MORSE dev, http://morse.openrobots.org)
<kaito> but getting real bullet phyiscs cooperate with armatures or ik would be nice - is huge design issue though
<skadge_> kaito: also in conjunction with an IK solver? the 'Inverse Kinematics' section, from the Bone panel does not make it clear
<kaito> for history's sake: robotics list was created by me, on request by benoit bolsee and herman bruyninckx
<skadge_> kaito: sorry :-)
<skadge_> we were discussing with Herman at that time
<skadge_> about using Blender for robotic simulation
<skadge_> and he went forward... sorry for tentatively rewritting history :-)
<kaito> :)
<kaito> sucess has many fathers!
<kaito> +c
<skadge_> kaito: in this week's meeting note, you were mentioning rigid body constraints. Which role do you see for them, compared to armatures?
<kaito> but the list is a bit quiet
<skadge_> yes, most of the discussions take place on morse-dev/morse-users
<skadge_> and those list are pretty active :-)
<kaito> rigid body constraint visualization and editing
<kaito> i want less buttons and more 3d
<skadge_> (it went this way because we quickly converged to a join project -> MORSE)
<skadge_> don't you think there's an overlap between armatures and rigid body constraints?
<kaito> not really... at least not for traditional armatures (character anims)
<skadge_> I mean, we have modeled complex robots (http://www.openrobots.org/morse/doc/latest/user/robots/pr2.html) with armatures...
<kaito> we need to find out the right way for overlap between robotics features and animators features
<skadge_> and if not the 2 constraints I mentionned above, we would be perfectly happy with armatures, I guess :-)
<kaito> or a good way to extend armatures for roboticists
<skadge_> yes, sure, I don't want to force anything in Blender design for robotics sake, which is a small niche.
<kaito> well if it's cool stuff, artists love it too :)
<skadge_> I was just trying to decide if I should recommend people to model their robots with IK or with rigid body constraints
<kaito> and of course we all love robots!
<skadge_> :-) I've watched Tears of Steels ;-)
<kaito> but which constraint types for armatures you need?
<skadge_> Most robotic joints are 1 DoF. Either hinges or prismatic joints (gliders).
<skadge_> hinges are easy to model by constraing the IK (like here: http://www.openrobots.org/morse/doc/latest/dev/armature_creation.html)
<skadge_> but as far as I know, I can not say: this bone's head is allowed to translate this amount, * without streching* (ie, without scaling)
<kaito> skadge_: what was itasc doing then? or - couldnt that ik system support such hinges?
<skadge_> Other issue is with 0-lenght bones: we often have 2 different joints that have the same origin (but typically different meshes attached)
<skadge_> I far I understood, itasc was just a 'better' IK solver, with less jitter, less singularities, better performances...
<kaito> well - slide joint could be simply an IK feature
<kaito> 0-length bones are not supported
<skadge_> kaito: yes, i've seen the bug report regarding this. It's 'by design' or merly an implementation issue?
<kaito> the bone definition is based on point, rotation + distance in Y
<kaito> without distance the bone system can't work
<skadge_> hum... no 'rotation alone', then
<kaito> real robots can't have singularies for joints either :)
<kaito> so what case you try to solve with it?
<skadge_> (i'm actually re-reading the ITasc doc: http://wiki.blender.org/index.php/Dev:Source/GameEngine/RobotIKSolver ...I'm wondering if the GUI exposes all the possibilities here...)
<kaito> anyway - i can't help with code work on it, so wouldnt anyone in morse be capable?
<kaito> or you could have sent over a student to apply for robo gsoc project :)
<kaito> mark in calendar for next year april!
<skadge_> kaito: typically, a shoulder for a humanoid robot has a 'yaw' (arm in front/arm on the side) and a 'pitch' (arm up/arm down). Bone 1 could go from torso to shoulder_yaw ; bone 2 from shoulder_yaw to shoulder_pitch.
<skadge_> They would have the same rotation center, though
<skadge_> ...yes, too late for GSoC
<skadge_> next year, we need to wake up earlier :-)
<kaito> ehh thats just a 2-dof hinge
<kaito> eh joint
<skadge_> yes, except each DoF may have different meshes attached
<kaito> how? (in real life)
<skadge_> (for instance here: http://www.netbooknews.com/wp-content/2011/07/nao.jpg. THe shoulder 'cap' is attached to the first DoF only)
* kaito doesn't see zero length really
<kaito> its just 1 joint with multiple children
* skadge_ is not sure to understand...
<kaito> inbetween two bones you have 'bone point' you can extrude new bones out of it
<skadge_> yes, that, I know :-)
<kaito> the cap looks like it
<skadge_> but here, it's important that the 2 joints have the *same rotation origin*
<skadge_> else the kinematics is wrong
<kaito> its still one joint, with 3 connections
<skadge_> if I attach the cap to another bone, this bone would rotate on the 2 axis of my parent bone, right?
<kaito> ehhh
<kaito> you better talk to robo riggers :)
<skadge_> yes :-)
<kaito> kjartan (who did ToS robot) asked me for better bone-parent feature for this
<kaito> did you notice in 2.66?
<skadge_> hum, no
<skadge_> but I'll definitely mail kjartan
<kaito> it allows to edit the pivot for things
<kaito> the transform for a bone-child object now is similar to how deform works
<skadge_> any doc/example somewhere?
<kaito> so you can move the bone in editmode, to set the pivot
<kaito> was very nice for robo rigs, since you always need to get good pivots
<kaito> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability
<kaito> 'animation fixes'
<kaito> its very simple to see on a 2 bone test
<kaito> parent a cube to 1 bone
<kaito> enter editmode and move bone around
<kaito> with 'relative parenting' the cube sticks to original place
<skadge_> hum I see
Input from Jeremy Davidson, main robot rigger on the Tears of Steel project:
When ive rigged robots before its mainly been a, look at the model then try make it work sort of thing.
Most tricks ive used are things like;
- copy rotation constraints only applied to one axis locally on 3 different bones aimed at a single control bone.
- Using IK chains without pole targets and using the axis locks and limits in the bone's deform menu.
- Layering armatures (to get around dependency graph issues)
The set up would come down to whats needed. As i said im not really sure how to rig anything until i see it. Also when working with robotic models ive always just parented the meshes to the bones needed. Though if the rig did become too complex i would create an extra layer of bones that the mesh parents too, then re-arrange and re-parent those bones where needed.
Based on above input and further investigation, the following procedure seems to work to create satisfactory armatures:
Starting with a mesh:
Shift+A
> Armature
)Tab
), select the head, snap the selection to the 3D cursor. This places the bone correctly between the 2 rigid bodies. Rename the bone into BodyA2Body2
(for instance, Torso2LShoulder
)E
)Pose Mode
, select the last bone, add a Bone Constraints
of type Inverse Kinematics
. Check the Stretch
option if you have slider joints in the kinematic chain. Bone Constraints
panel of the last bone. Now, if you move your IK target, you should see the whole armature moving accordingly.
Bone > Inverse Kinematics
menu. Select the enabled rotation axis and the rotation limits. If the joint is a slider (ie, a translation), use the Stretch
value to set the maximum translation allowed (in that case, you must use the Legacy
IK solver). Setting rotation limits should lead to a nice 3D display of reachable position for the joint.
Shift+click
the armature), then Ctrl+P
and select Set parent to... Bone
. Repeat this step for each bone.Limit scale
or Limit rotation
) on meshes to get the expected behaviour (for instance, to prevent scaling when the Stretch
IK limit is used, or when a mesh can only rotate on one axis of a multi-DoF joint).
The following stuff on blenderartists may be interesting for this issue
http://blenderartists.org/forum/showthread.php?306246-Dynamic-ragdoll-posing-v0-6
Despite large work done in #231, armatures (Blender name for kinematic chains) support in MORSE is sub-optimal.
This meta-bug tracks the issues and progresses made to improve it.
Amongst the open-issues:
creating armatures remains tricky. Doc could be improved. -> cf comment with updated doc belowBlender has also the concept of Rigid Body Constraints that looks nicer to use, but it is not plugged with IK solvers.Blender armatures do not support 0-length joints, which is an issue when several DoF have the same origin-> can be workarounded by modeling a multi-DoF joint + adding constraint (Limit rotation
) to the meshes when necessary, but...Armatures do not support pure translation. They only have a concept of 'streching' that scales the bone (and hence the attached meshes)-> can be workarounded by adding constraint (Limit scaling
) to the mesh.Access the IK is not yet exposed in MORSEFixed in #460.