Signal processing and algorithms

This section discusses the Xsens Sirius series signal processing and algorithm description.

 

• Signal processing pipeline
  • Strapdown integration
• Xsens sensor fusion algorithm for VRU and AHRS product types
• Xsens sensor fusion algorithm for the GNSS/INS product types
  • Lever Arm Correction
  • Filter profiles and heading behaviours
  • Initial Heading input
  • GNSS Platform
  • Real-Time Kinematic (RTK)
• Data output
  • Xbus output
  • NMEA output
  • CAN output
• Magnetic interference
  • Magnetic Field Mapping (MFM)
• Frames of reference

---

Signal processing pipeline

The Xsens Sirius 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 10 kHz, 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 Xsens Sirius series also attractive for systems with limited communication bandwidth. 

 

Xsens sensor fusion algorithm for VRU and AHRS product types

The Xsens Sirius VRU and AHRS 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 Xsens Sirius VRU and AHRS, 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 types

 

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 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 Sirius RTK GNSS/INS 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 the Sirius RTK GNSS/INS

 

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

 

Filter profiles and heading behaviours

The table below reports the different filter profiles and heading behaviours the user can set based on the application scenario. See the previous section for an explanation of this tiered approach. 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

 

 

Heading behaviours for the Sirius GNSS/INS and Sirius RTK GNSS/INS

Name	Description	Typical Applications
VRU	The yaw is initialized at 0° when the MTi is powered up. Once a GNSS fix is obtained, the yaw will converge to a North-referenced heading. The magnetic field is not used to estimate the yaw.	Environments where the magnetic field cannot be trusted (e.g. stabilized antenna platforms or pipeline inspection tools).
MagAided	Yaw output is mainly  based on magnetic heading, together with comparison of GNSS acceleration and the accelerometers. Although this combination makes the yaw more robust than magnetic field alone, a homogeneous or calibrated-for magnetic field is essential for good-performance yaw.	Environments with a homogeneous magnetic field, and when the absolute heading observability based on GNSS data is too low—especially if your application is often standing still or moving very slowly.

Initial Heading input

Among the available filter profiles for the Sirius GNSS/INS and Sirius RTK GNSS/INS, only the MagAided heading profile provides a North-referenced heading immediately after power up. For the VRU heading profile, the yaw angle initializes at 0 degrees. Once a GNSS fix is obtained and the MTi reaches sufficient motion, the yaw will converge to a North-referenced heading.

If the initial heading of the MTi is approximately known at startup, for example from an external sensor or a known mounting orientation, it is strongly recommended to manually set the initial heading using the SetInitialHeading low level communication command. Refer to the MT Low Level Communication Protocol Documentation for details.

For the MagAided filter profile, manually setting the initial heading is only recommended if an even more accurate heading is available from an external source than the magnetometer-based heading at power up.

 

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.

 

Real-Time Kinematic (RTK)

The Sirius RTK GNSS/INS 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 Documentation). In the latter case, the NTRIP client in MT Manager can be setup to provide the correction data.

 

 

Data output

The Xsens Sirius 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 Xsens Sirius series can output its data. CAN-FD functionality is also available with firmware version 1.3.0 or higher. More information on the CAN output can be found in the MT CAN Protocol Documentation.

 

 

 

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 Xsens Sirius 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 Xsens Sirius series. The magnetic field mapping procedure is extensively documented in the Magnetic Calibration Manual.

Frames of reference

The Xsens Sirius 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 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 Xsens Sirius series have predefined output options for North-East-Down (NED) and North-West-Up (NWU). Since the Xsens Sirius VRU and AHRS cannot receive real time positioning from a GNSS receiver, the user must set correct positional coordinates to allow the Xsens Sirius VRU and AHRS to construct the reference frame, magnetic and gravity models.

 

 

Default sensor fixed coordinate system(S_xyz) for the Xsens Sirius Robust Trackers : IMU/VRU/AHRS/MRU (left) and GNSS/INS & RTK GNSS/INS (right).                  

 

[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.