Skeleton Tracking

Overview
The cameras of the Kinect are now used to build skeletons that will allow the system to track players that will be used to detect the movement and will eventually send the data to the robot to imitate.
Background
Now that depth data has been experimented with, it is time for me to understand how the Kinect can determine a skeleton of a player by using the depth data detected. Then manipulate the API for use.
The Kinect for Windows can detect 20 joints:

• Right Hand
• Right Wrist
• Right Elbow
• Right Shoulder
• Head
• Centre Shoulder
• Left Hand
• Left Wrist
• Left Elbow
• Left Shoulder
• Spine
• Centre Hip
• Right Hip
• Left Hip
• Right Knee
• Left Knee
• Right Ankle
• Left Ankle
• Right foot
• Left foot

All point have an X,Y,Z point. The Z point is the distance (meters) from the Kinect. If a joint is not quite in view then the Kinect can determine where a joint might be and class it has inferred. The Kinect can only track 2 players full skeleton but can track 6 players presence. Each skeleton has a Unique Tracking ID

Activity
The first activity is to display the skeleton of the player. To do this, the viewers used previously can be dragged in; the "KinectSkeletonViewer" can be dropped on the canvas and data bind to the Kinect to display the skeleton. However this visual representation is useful for a visual representation, it doesn't give any data values.

The next activity is to place objects where skeleton points are. The Kinect Development Tool kit supplies a demo that does this. However the demo was built for Kinect SDK version 1.0 and since then numerous releases have been released including Version 1.5 that makes many methods obsolete and therefore creating unsafe code when the obsolite methods are used. This includes "MapFromSkeletonPoint" method, featured heavily in the Microsoft demo for version 1.0. This method has been replaced with "MapDepthPointToColorPoint" method that uses a different class. 
The challenge has been to understand what parameters are needed and utilising them.
The program as it stands now positions an ellipse to a skeleton point position. The next step is to get the position data of a skeleton point (right hand) in to a label but updating in such a way not to cause performance issues.
The code below shows how the label content will display the right hand z position (distance from the Kinect)

label1.Content = first.Joints[JointType.HandRight].Position.Z;

Testing has shown that because it is only updating a small label field the performance is not effect when showing on every value change. This is extremely useful for future development as it will enable action to be performed depending on the players location.