Hello and welcome!

We have worked on a Kinect project for a client, so we have bit of experience using Kinect. I have read several requests by now about using Kinect to animate a character in real-time - and I am interested in it myself. (I do not not need it for a specific project, but I like the challenge. ;-)
I hope to find the time to create a sample for this (but in 2011 there is not enough time left).

Here are some general thoughts:

Input data:
Joint positions (delivered by Kinect)
Joint contraints (defined manually)
Character skeleton (defined manually)

Output data:
The bone orientations for the skeleton (= SkeletonPose in DR terms), obeying the joint constraints.

Notes:
We could also control the position of the root bone using the Kinect data, which is a simpler task and I will ignore this for now.
In general, the Kinect input should always be validated and very bad input data should be filtered (e.g. impossible positions of limbs or sudden changes in the input data.)
I haven't searched the web, but we have internally discussed a few approaches.

Approach A: Manual mapping of bone orientations.
The character skeleton should have the same (or a very similar) bone hierarchy as the Kinect skeleton. (You can use the SkeletonMapper later to map the pose to different skeletons.)
Then for each bone:
Compute the direction vector of the bind pose of the bone using the start and end joints.
Also compute the direction vector using the kinect joint positions.
Create a rotation that rotates the bone from the two direction vectors (using QuaternionF.Create()).
Apply this orientation to the bone (using SkeletonHelper.RotateBoneAbsolute).

For the constraints:
Manually check if each bone orientation is in an allowed range. If necessary reduce the bone rotation before applying.
Or to get a smoother solution: After you have the unconstrained skeleton pose, iterate over all bones of the skeleton and if a bone rotation is invalid, correct the rotation by rotating the child bone AND the parent bone a bit. (Use weight factor to rotate parent bones and large bones less). Do this several times for the all skeleton and hope that it converges.

Approach B: Using IK-Solvers
Use only specific joint positions from the Kinect data (e.g. hand, head, feet) and use the IKSolvers to let the skeleton reach for those posititions. Some IKSolver support limits (using delegate functions in which you apply a manual correction).

Approach C: Using Radoll to solve contraints
Compute an unconstrained skeleton pose using one of the above methods.
Create a Ragdoll (including joint limits).
Use ragdoll motors to drive ragdoll to the unconstrained skeleton pose. The contraint solver in the physics simulation will take care of the constraints.
Then use the ragdoll to update the final skeleton (using Ragdoll.UpdateSkeletonFromBodies).

Approach D: Ragdoll with position contraints (The "Marionette" Approach)
Create a Ragdoll (including joint limits).
Add additional physics contraints (e.g. soft BallJoints) that pull important body parts to the Kinect joint positions.
Then use the ragdoll to update the final skeleton (using Ragdoll.UpdateSkeletonFromBodies).

Those are just some ideas we have been throwing around. I am sure there are other ideas out there.

Interesting... we will see what we can do. Thanks for that tip.

Making the ragdoll stable under such complex conditions can be tricky. Here are some random tips:

• Start with an empty Simulation without force effects (no damping, no gravity). In the simulation setttings: Set the fixed time step size to a very small value (maybe 5ms or even 1ms) and increase the MaxNumberOfSteps. Increase the number of constraint iterations in the simulaton settings (maybe to 20 or higher). Now we have higher quality simulation conditions. If we can get it stable with these settings, we can optimize it later. If we cannot get it stable under these simulation conditions, we are doomed anyway ;-)
• Always try to visualize the  constraint targets to be sure the inputs for the constraints are in a valid range and are not scaled or offset in strange ways.
• Create the ragdoll step by step. Do not start with the full ragdoll. Start with one body (e.g. the pelvis). Make it follow the Kinect data. When this is stable, add the next body and constraint. Do everything step by step, on constraint/motor/body/limit after the other.
• The parameters that need very careful tweaking are:
  spring and damping of a motor,
  error reduction and softness of the constraints, 
  (Sidenote: spring+damping can be converted to error reduction+softness using the ConstraintHelper class.)
  and the MaxForce of constraints (the max force of marionette attachment joints must be limited so that they are weaker than the ragdoll joints and limits).

 

To compute SrtTransforms from the Kinect data:
Separate translation and rotation. At first I would only concentrate on rotations. Compute the rotations of the SrtTranform rotations from the bone directions as described for approach A in my previous post.

No problem. A single SrtTransform does not give you enough information to know about the direction of a bone.
Have a look at the DrawBones() code in the BindPoseSample.cs (in the CharacterAnimationSample). This method draws lines that represent the bones. Here is a code snippet from it:

 

To know the direction of a bone you get the absolute bone poses - which describes the scale, rotation and translation in the local space of the model. The translations describes the positions of the joints (= the start positions of the bones). If you subtract (and then normalize) the translation of a bone from its parent bone, then you have the direction of the parent bone.

This implies that, in general, you cannot know the direction of the last bones in the skeleton.

In some cases the 3D artist that created the skeleton has followed a certain rule, for example: The bone direction is in the direction of the local x axis of the bone. In this case you could compute the bone direction from the SrtTransform alone:
  Vector3F.UnitX  is the direction in the local space of the bone.
  absoluteBonePose.Rotation.Rotate(Vector3F.UnitX) is the direction of the bone in model space.

But in general, you can only compute the bone directions as the differences of joint positions.

The samples in the CharacterAnimationSample project show how to move a ragdoll to a target SkeletonPose (see CollisionDetectionOnlyRagdollSample and/or KinematicRagdollSample). When used like this, the ragdoll limits are not applied. Ragdoll limits were designed for the case where the animation is driven by physics (as in the PassiveRagdollSample or the Marionette approach).