Signal processing and algorithms

This section discusses the MTi 600-series signal processing and algorithm description.

• Signal processing pipeline
  • Strapdown integration
• Xsens sensor fusion algorithm for VRU/AHT and AHRS product types
• Xsens sensor fusion algorithm for the GNSS/INS product type
  • Lever Arm Correction
  • Smoothers
  • Continuous Zero Rotation Update
  • Filter profiles
  • Initial Heading input
  • GNSS Platform
  • Real-Time Kinematics
• Data output
  • Xbus output
  • NMEA output
  • CAN output
• GNSS input
  • u-blox (UBX) input
  • NMEA input
  • Septentrio (SBF) input
  • Trimble (GSOF) input
• Magnetic interference
  • Magnetic Field Mapping (MFM)
• Frames of reference

Signal processing pipeline

The MTi 600-series is a self-contained product. All calculations and processes such as sampling, coning & sculling compensation and the Xsens sensor fusion algorithm run on board.

Strapdown integration

The Xsens optimized strapdown algorithm performs high-rate dead-reckoning calculations up to 2000 Hz, allowing accurate capture of high frequency motions. This approach ensures a high bandwidth. Orientation and velocity increments are calculated with full coning & sculling compensation. These orientation and velocity increments are suitable for any 3D motion tracking algorithm. Increments are internally time-synchronized with other sensors. The output data rate can be configured for different frequencies. See #Output data rates. The inherent design of the signal pipeline with the computation of orientation and velocity increments ensures there is absolutely no loss of information at any output data rate. This makes the MTi 600-series also attractive for systems with limited communication bandwidth. 

Xsens sensor fusion algorithm for VRU/AHT and AHRS product types

MTi-620 and MTi-630(R) run the newest Xsens sensor fusion algorithm implementing the latest Xsens insights. It optimally estimates the orientation with respect to an Earth fixed frame utilizing the 3D inertial sensor data (orientation and velocity increments) and 3D magnetometer data.

The Xsens sensor fusion algorithm uses assumptions to obtain the orientation estimations. Since the assumptions may be more or less valid based on the characteristics of the typical dynamics of the application, and since the magnetic field differs per application, the Xsens algorithm makes use of a set of filter profiles to be able to use the correct assumptions given the application. This way, the algorithm can be optimized for different types of movements and conditions.

With the MTi-620 and MTi-630(R), the user can configure different algorithm behaviours by selecting a “base” filter profile and, next to that, a heading behaviour. See image below.

Filter profile and heading behaviour selection: a tiered approach

The “base” filter profile selection affects the general behaviour of the device, mainly based on the nature of the typical expected dynamics of the application. The heading behaviour, as the name suggests, affects the heading/yaw output of the MTi, and determines how the magnetometer measurements are interpreted. This tiered approach gives more freedom to select the desired behaviour for different user application scenarios. The tables below summarize the filter profile and heading behaviour options.

Every application is different and results may vary from setup to setup. It is recommended to reprocess recorded data with different filter profiles in MT Manager to determine the best filter profile for your specific application.#1

Xsens sensor fusion algorithm for the GNSS/INS product type

The Xsens sensor fusion algorithm in the GNSS/INS products has several advanced features. The algorithm adds robustness to the orientation and position estimates by combining measurements and estimates from the inertial sensors, magnetometer, barometer and a GNSS receiver in order to compensate for transient accelerations and magnetic disturbances.

The GNSS status is continuously monitored and the filter accepts GNSS data when available and sufficiently trustworthy. When the product has limited/mediocre GNSS reception or even no GNSS reception at all (e.g. during outages), the fusion algorithm seamlessly adjusts the filter settings in such a way that the highest possible accuracy output is maintained. The MTi will continue to output position, velocity and orientation estimates, although the accuracy is likely to degrade over time as the filters can only rely on dead-reckoning. If the GNSS outage lasts longer than 45 seconds, the MTi stops the output of the position and velocity estimates, and resumes sending these outputs once the GNSS data becomes acceptable again.

Lever Arm Correction

Due to the improvement in position accuracy on MTi-680(G) devices with RTK support, it is important to define the distance between the MTi and the GNSS antenna, also known as the GNSS lever arm. The figure below highlights the effect of the lever arm on measurements taken with cm-level accuracy.

Lever arm correction for MTi-680G

The lever-arm describes the position of the GNSS antenna with respect to the origin of measurement of the MT device (see Design and Packaging). This information is essential to the sensor fusion algorithm in order to correct its position and velocity measurements accordingly. The lever arm can be set from the Device Settings window in MT Manager, or by using the setGnssLeverArm low-level communication command (refer to the MT Low Level Communication Protocol Document for details). More background information on the GNSS lever arm can be found on BASE.

Example of lever arm measurements

Smoothers

The GNSS/INS products (MTi-670(G) and MTi-680(G) have optional sensor fusion functions called smoothers for reducing sudden jumps in the output data that may arise from fusing low-rate GNSS receiver messages with high-rate inertial sensor data. There is a smoother for orientation data for both the MTi-670(G) and MTi-680(G), and a position/velocity smoother for the MTi-680(G). The smoothers can be enabled from the Device Settings window in MT Manager, or by using the setOptionFlags low-level communication command (see the MT Low Level Communication Protocol Document for details).

Continuous Zero Rotation Update

The Continuous Zero Rotation Update (CZRU) is a feature that is currently only available for the MTi-680(G). The purpose of the CZRU is to reduce the undesired effects of gyroscope bias, such as drift of the orientation output. Although all MTi products are individually calibrated for various parameters, including sensor bias, the aging and use of Motion Trackers in industrial environments can cause sensor biases to change during the product's lifetime. Because of that, the filters of the MTi are continuously re-restimating calibration parameters such as sensor bias while they are powered up. If enabled, the Continuous Zero Rotation Update will execute a background algorithm that will automatically initiate a gyroscope bias estimation sequence whenever the Motion Tracker is motionless.

The Manual Gyro Bias Estimation function is similar to the Continuous Zero Rotation Update, except for the fact that for each individual update, the Manual Gyro Bias Estimation function has to be initiated by the user through a command. For more information, refer to BASE: Manual Gyro Bias Estimation

The Continuous Zero Rotation Update can be enabled through the Device Settings window in MT Manager, or through the SetOptionFlags low-level command (see MT Low Level Communication Protocol Document).

Filter profiles

The table below reports the different filter profiles the user can set based on the application scenario. Every application is different and results may vary from setup to setup. It is recommended to reprocess recorded data with different filter profiles in MT Manager to determine the best results in your specific application.#1

Initial Heading input

Out of the filter profiles available for the MTi-670(G)/680(G), only the GeneralMag filter profile will provide the user with a North-referenced heading when the MTi is powered up. For all other filter profiles, the Yaw will initialize at 0 degrees. As soon as a GNSS fix is available and the MTi starts moving at a sufficient velocity, the Yaw will converge to a North-referenced heading.

If the initial heading of the MTi is approximately known at initialization time, for instance, based on an external sensor or a known starting orientation, then it is highly recommended to manually set the initial heading value. This can be done using the SetInitialHeading low-level communication command. Refer to the MT Low Level Communication Protocol Documentation for more information.

GNSS Platform

u-blox GNSS receivers support different dynamic platform models in order to adjust the navigation engine to the expected application environment. The GNSS/INS products can be configured to communicate a desired platform model upon start-up. This enables the user to adjust the u-blox receiver platform to match the dynamics of the application. The setting influences the estimates of Position and Velocity and therefore, it affects the behavior of the Xsens filter output.

The platform model can be configured through the Device Settings window in MT Manager (version 2021.4 and later) or using low-level communication by providing the GNSS Platform ID. For more details on the low-level commands used to set the GNSS Platform (SetGnssReceiverSettings), refer to the MT Low Level Communication Protocol Document. For more details on GNSS platform settings, refer to the u-blox Receiver Description Manual.

Alternatively, when interfacing with a GNSS receiver through NMEA communication, the received NMEA position data is used ‘as is’, independent of the GNSS platform setting.

Real-Time Kinematics

The MTi-680G supports centimeter-level position accuracy through RTK (Real-Time Kinematic), which uses correction messages from a base station with a known position. The RTK correction data must be supplied as RTCM3 messages, either via the dedicated RTCM input connector (see Functional description) or via the host interface as RTCM messages embedded in xbus (see XMID_ForwardGnssData  in the MT Low-Level Communication Protocol Document). In the latter case, the NTRIP client in MT Manager can be setup to provide the correction data.

The MTi-680 supports centimeter-accurate position data from an external GNSS receiver. The method of providing correction messages to the external GNSS receiver is entirely up to the end user.

Data output

The MTi 600-series product variants can output many different data types at many different frequencies. Below is a summary of the most relevant data and maximum output data rates. A full overview is available in the MT Low Level Communication Protocol Documentation.

Xbus output

The Xbus protocol is Xsens’ standard output protocol utilizing the MTDATA2 data message structure. This output provides a lot of flexibility and enables users to access all functionality of the MTi product range. The Xbus output format is shared with all other MTi products in the Xsens portfolio, so switching between hardware platforms is very easy. More information is available in the MT Low Level Communication Protocol Documentation.

NMEA output

NMEA output is a string output mode which outputs data in the commonly used NMEA 0183 format. More information is available in the MT Low Level Communication Protocol Documentation.

CAN output

The CAN output is an industrial standard interface over which the MTi 600-series can output its data. More information on this output can be found in the MT Low Level Communication Protocol Documentation and Family Reference Manual.

GNSS input

The MTi-670 and MTi-680 require data from an external GNSS receiver to provide a full GNSS/INS solution. This can be achieved by connecting a GNSS receiver that communicates with one of the following supported protocols:

• u-blox' UBX protocol
• NMEA sentences (officially supported with firmware version 1.6.0 and up)
• Septentrio's SBF protocol (beta support with firmware version 1.8.0 and up)
• Trimble's GSOF protocol (beta support with firmware version 1.8.0 and up)

The use of each of these supported protocols is discussed in more detail in the paragraphs below.

u-blox (UBX) input

When connecting to a u-blox receiver (e.g. u-blox MAX-M8), the MTi will configure it correctly on start-up. No prior configuration of the u-blox receiver is required. It is, however, recommended to inform the MTi of what type of u-blox receiver is connected. This can be done using the Device Settings window in MT Manager (version 2021.4 and later), or using an Xbus message called SetGnssReceiverSettings, described in the MT Low Level Communication Protocol Documentation. The user can select one of the officially supported u-blox receiver series: MAX-M8 (default), NEO-M8 or ZED-F9.

NMEA input

Almost all GNSS receivers support the output of NMEA messages, which means that this functionality enables the use of virtually any external GNSS receiver. It is important to note that both the GNSS receiver and the MTi must be configured prior to connecting both systems to each other. The NMEA input mode can be enabled using the Device Settings window in MT Manager (version 2021.4 and later), or using an Xbus message called SetGnssReceiverSettings, described in the MT Low Level Communication Protocol Documentation.

The table below summarizes the settings needed to configure the MTi-670/680 to use the NMEA input mode. This will enable the MTi to use the GNSS data and provide the user with a full GNSS/INS solution. The MTi will also synchronize its internal clock with the UTC time that is present in the sentences.

An example of how to setup an external GNSS receiver using the NMEA protocol can be found on BASE.

Septentrio (SBF) input

Please note that both the GNSS receiver and the MTi must be configured prior to connecting both systems to each other. The Septentrio input mode can be enabled using the Device Settings window in MT Manager (version 2021.4 and later), or using an Xbus message called SetGnssReceiverSettings, described in the MT Low Level Communication Protocol Documentation.

The table below summarizes the settings needed to configure the MTi-670/680 to use the Septentrio input mode. This will enable the MTi to use the GNSS data and provide the user with a full GNSS/INS solution. The MTi will also synchronize its internal clock with the UTC time that is present in the sentences.

An example of how to setup an external GNSS receiver using the SBF protocol can be found on BASE.

Trimble (GSOF) input

Please note that both the GNSS receiver and the MTi must be configured prior to connecting both systems to each other. The Trimble input mode  can be enabled using the Device Settings window in MT Manager (version 2021.4 and later), or using an Xbus message called SetGnssReceiverSettings, described in the MT Low Level Communication Protocol Documentation.

The table below summarizes the settings needed to configure the MTi-670/680 to use the Trimble input mode. This will enable the MTi to use the GNSS data and provide the user with a full GNSS/INS solution. The MTi will also synchronize its internal clock with the UTC time that is present in the sentences.

An example of how to setup an external GNSS receiver using the GSOF protocol can be found on BASE.

Magnetic interference

Magnetic interference can be a major source of error for the heading accuracy of any AHRS, as an AHRS uses the magnetic field to reference the estimated orientation on the horizontal plane with respect to the (magnetic) North#3. A severe and prolonged distortion in that magnetic field will cause the magnetic reference to be inaccurate. The MTi 600-series has several ways to cope with these distortions to minimize the effect on the estimated orientation, which are discussed in the sections below.

Magnetic Field Mapping (MFM)

When the distortion moves with the MTi (i.e. when a ferromagnetic object solidly moves with the MTi module), the MTi can be calibrated for this distortion. Examples are the cases where the MTi is attached to a car, aircraft, ship or other platforms that can distort the magnetic field. It also handles situations in which the sensor has become magnetized. These types of errors are usually referred to as soft and hard iron distortions. The Magnetic Field Mapping procedure compensates for both hard iron and soft iron distortions.

The magnetic field mapping (calibration) is performed by moving the MTi mounted on the object/platform that is causing the distortion. The results are processed on an external computer (Windows or Linux), and the updated magnetic field calibration values are written to the non-volatile memory of the MTi 600-series. The magnetic field mapping procedure is extensively documented in the Magnetic Calibration Manual.

Frames of reference

The MTi 600-series uses a right-handed coordinate system. The default sensor-fixed frame (S_xyz) is defined as shown in the figures below. The frame is also printed on the side of the module or the back side of robust trackers. For a more exact location of the sensor frame origin, refer to Design and Packaging. When the sensor is rigidly attached to another object or vehicle, it is possible to rotate the sensor-fixed frame S_xyz to an object coordinate frame (O_xyz).#5 The default local earth-fixed frame (L_XYZ) is East-North-Up (ENU). In addition, the MTi-6x0 has predefined output options for North-East-Down (NED) and North-West-Up (NWU). Specifically, for the GNSS/INS models, the Local Tangent Plane (LTP) is a local linearization of the Ellipsoidal Coordinates (Latitude, Longitude, Altitude) in the WGS-84 Ellipsoid, based on the real time position data retrieved from the GNSS receiver. Since the MTi-620 and MTi-630(R) cannot receive real time positioning from a GNSS receiver, the user must set correct positional coordinates to allow the MTi-620 or MTi-630(R) to construct the reference frame, magnetic and gravity models.

Default sensor fixed coordinate system (S_xyz) for the MTi 600-series module

Default sensor coordinate system for the MTi-630R and MTi-680G

[1] Refer to the BASE article: Recording a data file to be reprocessed in MT Manager.

[2] The General filter profile is only recommended for users who are looking for similar behaviour to the previous generation Xsens products in the typical applications suggested in the table. Using the General filter profile is not recommended for new designed applications.

[3] Note: Under default settings, Yaw (heading) equals 90 degrees when the X-axis of the MTi points north.

[4] For more information on the capabilities of AHS, refer to the BASE article: AHS. Note that in the previous Xsens products, AHS was activated by means of a separate setting.

[5] How to define a new object coordinate system can be found in the Family Reference Manual.