1 Introduction
MVN Analyze/Animate, developed by Xsens, is a tool to capture and compute the 6DOF motion data of
an inertial sensor-driven system. It allows the export of the data to third party applications such as Motion
Builder, making the data available to drive rigged characters in e.g. animations. The data transfer to
other applications is primarily file based when using MVN Analyze/Animate. With the XME API (SDK)
there are many other options.
In many situations it is attractive to keep the ease of use of MVN Analyze/Animate, while receiving the
motion capture data in real-time in another application, even on another PC possibly physically remote
from the MVN system.
This document defines a network protocol specification for this purpose. It describes the transport
medium, the given data and the datagrams to be sent and received over the network, as well as the
control sequences the server and clients will use to communicate states and requests during the
sessions. The network communication is mainly required to be fast/real-time, other quality criteria are
secondary.
This document describes MVN Analyze/Animate Real-time Network Streaming. The streaming feature
enables computers that run MVN Analyze/Animate to stream the captured data over a network to other
client computers.
1.1 Perceived Usage
1.1.1 Usage in real-time previsualization and simulation VR setups
Many software packages (e.g. MotionBuilder) and experimental VR rigs use single computers to do
specific processing and hardware interfacing tasks, such as driving motion platforms, real-time rendering
to a screen, or interfacing with a motion capture device. In this scenario, a PC set up with MVN
Analyze/Animate could service one (or more) motion captured persons. This requires immediate,
regularly timed delivery of state (pose) packets. The UDP protocol is most suitable for this task because
it delivers packets without congestion control and dropped packet checking. MVN Analyze/Animate real-
time network streaming protocol is based on UDP and is specified in this document.
To support scenarios like this for usage with 3rd party tools as a client application, Xsens has developed
several plug-ins. MVN Analyze/Animate plug-ins are available for Autodesk Motion Builder,
Autodesk Maya and Unity3D. These tools use protocols specified in this document to receive motion
capture data in real-time.
The client side plug-ins for MotionBuilder and Maya can be requested and purchased separately at
Xsens.
The Unity3D plug-in is available for free at: https://www.assetstore.unity3d.com/en/#!/content/11338
(Version: 1.0 (Apr 25, 2014), Size: 1.6 MB, this requires Unity 4.0.1 or higher)
1.1.2 Network Streamer and Network monitor
To send motions from MVN Analyze/Animate, go to Options > Preferences > Miscellaneous > Network
Streamer and choose the desired protocol. The motion can also be received by MVN Analyze/Animate
go to File > open Network Monitor. The Network Monitor will also show the local axis for each segment.
Also note that the red triangle in the origin is representing the x-axis.
Document MV0305P.K
© Xsens Technologies B.V. MVN Analyze/Animate real-time network streaming
2
1.1.3 Usage in multi-person or other complex motion capture setups
In roll-your-own motion capture setups, often additional data is captured. An example could be medical
data, or data gloves. Another setup might capture multiple subjects at once. The TCP protocol would be
most suitable for this task as this protocol guarantees that the data stream is completely sent, potentially
at the expense of near real-time delivery. However UDP also suffices in a well-designed network setup
as there will be nearly no, or very little, packet loss.
Advantages for motion capture setup builders include:
Not necessary to interface with XME API (SDK).
Processing CPU time required for inertial motion capture is done on a separate PC, freeing up
resources for other processing;
Calibration and real-time pre-viewing (e.g. for assessment of motion capture quality) can be
done on the processing PC using MVN Analyze/Animate itself.
Document MV0305P.K
© Xsens Technologies B.V. MVN Analyze/Animate real-time network streaming
3
2 Transport Medium
2.1 Network Environment
The network environment will be assumed to be a local 100 Mbit Ethernet network, larger network
topologies are not considered and can be covered by file transfer of the already given file export
functionality or later extensions to the network protocol. Thus, few packet loss or data corruption during
transfer is to be expected, as well as constant connectivity.
2.2 Network Protocol
Network communication uses a protocol stack, thus the streaming protocol will be implemented on top
of a given set of protocols already available for the network clients. In this case, the layers to build upon
are IP and UDP (or TCP, which is also supported). IP (Internet Protocol, RFC 791) is the network layer
protocol used in Ethernet networks and defines the source and destination of the packets within the
network. Upon this, UDP (User Datagram Protocol, RFC 768) is used to encapsulate the data. The UDP
Protocol is unidirectional, and contrary to TCP (Transmission Control Protocol, RFC 793) it is stateless
and does not require the receiver to answer incoming packets. This allows greater speed.
2.3 Default Port
The default Port to be used on the network is 9763. This Port is derived from the XME API (9=X, M=6,
E=3). MVN Analyze/Animate server will default to this Port.
It is of course possible to define an arbitrary Port if needed.
2.4 Datagram
The motion capture data is sampled and sent at regular time intervals for which the length depends
upon the configuration of MVN Analyze/Animate. Common sampling rates lie between 60 and 240 Hertz.
The update rate of the real-time network stream can be modified separately. The data content in the
datagram is defined by the specific protocol set, but basically, the positions and rotation of all segments
of the body at a sampling instance are sent away as one or more UDP datagrams.
Each datagram starts with a 24-byte header followed by a variable number of bytes for each body
segment, depending on the selected data protocol. All data is sent in ‘network byte order’, which
corresponds to big-endian notation.
Framed text indicates items that are sent as part of the datagram.
2.4.1 Header
The header contains the type of the data and some identification information, so the receiving end can
apply it to the right target.
Datagram header
6 bytes ID String
4 bytes sample counter
1 byte datagram counter
1 byte number of items
4 bytes time code
1 byte character ID
7 bytes reserved for future use
2.4.1.1 ID String
The so-called ID String is an ASCII string which consists of 6 characters (not terminated by a null
character). It serves to unambiguously identify the UDP datagram as containing motion data of the
format according to this specification. Since the values in the string are characters, this string is not
converted to a big-endian notation, but the first byte is simply the first character, etc.
These are the ASCII and hexadecimal byte values of the ID String:
ASCII M X T P 0 1
Hex 4D 58 54 50 30 31
M: M for MVN
X: X for Xsens
T: T for Transfer
P: P for Protocol
##: Message type. The first digit determines what kind of packet this is and the second digit determines
the format of the data in the packet
Message type Description
01 Pose data (Euler) ← MotionBuilder +Maya
Absolute position and orientation (Euler) of segments
Y-Up, right-handed
This type is used by the Motion Builder + Maya plug-in
Supported by MVN Analyze/Animate network monitor
02 Pose data (Quaternion) ← MVN Analyze/Animate Network Monitor
Absolute position and orientation (Quaternion) of segments
Default mode Z-Up, right-handed or Y-Up
Supported by MVN Analyze/Animate network monitor
03 Pose data (Positions only, MVN Optical marker set 1)
Positions of selected defined points (simulating optical markers), typically 38-
46 points. Multiple data sets are available.
This datagram is used by the Motion Builder plug-in v1.0.
Partially supported by MVN Analyze/Animate network monitor.
MVN Analyze/Animate has a limited ability to re-integrate these marker
positions into a character. The segment orientations will not be updated.
Therefore, when only this datagram is received, the resulting character can
appear incorrect.
04 Deprecated: MotionGrid Tag data
05 Pose data (Unity3D)
Relative position and orientation (Quaternion) of segments
Uses alternative segment order
Left-handed for Unity3D protocol
Supported by MVN Analyze/Animate network monitor
10 Deprecated, use 13: Character information scale information
11 Deprecated, use 13: Character information prop information
12 Character information meta. data
name of the character
MVN character ID (BodyPack or Awinda Station ID)
>
Supported by MVN Analyze/Animate network monitor
Document MV0305P.K
© Xsens Technologies B.V. MVN Analyze/Animate real-time network streaming
5
Message type Description
13 Character information scaling information, including prop and null-pose
Supported by MVN Analyze/Animate network monitor
20 Joint Angle data
Joint definition and angles
NOT supported by MVN Analyze/Animate network monitor.
21 Linear Segment Kinematics
Absolute segment position, velocity and acceleration
Partially supported by MVN Analyze/Animate network monitor.
MVN Analyze/Animate has a limited ability to re-integrate this data into a
character. The segment orientations will not be updated. Therefore, when only
this datagram is received, the resulting character can appear incorrect.
22 Angular Segment Kinematics
Absolute segment orientation, angular velocity and angular acceleration
Partially supported by MVN Analyze/Animate network monitor.
MVN Analyze/Animate has a limited ability to re-integrate this data into a
character. The segment positions will not be updated. Therefore, when only
this datagram is received, the resulting character can appear incorrect.
23 Motion Tracker Kinematics
Absolute sensor orientation and free acceleration
Sensor-local acceleration, angular velocity and magnetic field
NOT supported by MVN Analyze/Animate network monitor.
24 Center of Mass
Absolute position of center of mass
NOT supported by MVN Analyze/Animate network monitor.
25 Time Code
Time code string
NOT supported by MVN Analyze/Animate network monitor.
Please note that the message type is sent as a string, not as a number, so message type “03” is sent
as hex code 0x30 0x33, not as 0x00 0x03.
2.4.1.2 Sample Counter
The sample counter is a 32-bit unsigned integer value which is incremented by one, each time a new
set of motion tracker data is sampled and sent away. Note that the sample counter is not to be
interpreted as a time code, since the sender may skip frames.
2.4.1.3 Datagram Counter
The size of a UDP datagram is usually limited by the MTU (maximum transmission unit, approx. 1500
bytes) of the underlying Ethernet network. In nearly all cases the entire motion data that was collected
at one sampling instance will fit into a single UDP datagram. However, if the amount of motion data
becomes too large then the data is split up into several datagrams.
If motion data is split up into several datagrams then the datagrams receive index numbers starting at
zero. The datagram counter is a 7-bit unsigned integer value which stores this index number. The most
significant bit of the datagram counter byte is used to signal that this datagram is the last one belonging
to that sampling instance. For example, if motion data is split up into three datagrams then their
datagram counters will have the values 0, 1 and 0x82 (hexadecimal). If all data fits into one UDP
datagram (the usual case) then the datagram counter will be equal to 0x80 (hexadecimal).
The sample counter mentioned above can be used to identify which datagrams belong to the same
sampling instance because they must all carry the same sample counter value but different datagram