Table of contents

RoadTest: Xsens Position and Orientation Sensing GNSS/INS Dev Kit

Author: saadtiwana_int

Creation date: 7 Nov 2022

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: There are similar (but not necessarily same) parts available from companies like VectorNav, PNI Corp, Analog Devices, Inertial Sense, TDK Invensense, etc. However, for this type of modules the detailed specifications matter, which makes it very hard to compare two devices unless they list exactly the same specs. In addition, the various devices offer varying levels of processing on the raw data, which further complicates a direct comparison.

What were the biggest problems encountered?: Although this is the "RTK" variant of the development kits, since the kit does not include another Zed-F9P board to act as RTK "base station", it was not possible to test the RTK performance of the system. I tried hard to find a free NTRIP service close to me, but the closest I could find was a few hundred kilometers away.

Detailed Review:

IMPORTANT NOTE: 

Much of the material related to my experiments and review of the Xsens MTi-680-DK is contained inside the blog posts I published in the preceding weeks and linked in the post below. Thus, this review post mostly contains things not covered in those posts. Readers are highly encouraged to read-through the linked blog posts for more details. I will also update this review post with links to any blog posts related to the MTi-680 I publish afterwards.

Introduction:

Among the various domains in engineering, I enjoy working most at the interface between the physical and virtual/software world. This usually means sensors as well as electromechanical control/actuation systems. The MTi-680-DK being a versatile sensor (containing gyros, accelerometers, magnetometers, barometer, temp sensor), and that too a fairly high performance one, made it a very exciting product for me to road-test. I am very glad and thankful that I was given this opportunity.

The MTi-680-DK development kit being reviewed is from the company Xsens, which is a company headquartered in Netherlands. Xsens is now part of Movella, which is a parent company consisting of Xsens, mCube and Kinduct. In a nutshell, the company is designing, building and selling devices for motion sensing/capture, tracking and analysis. Clicking the "Products" menu on the Xsens webpage provides a good overview of the various offerings from Xsens:All the devices under the "Inertial Sensor Module" heading below are from the MTi category of devices.

Over the weeks, while browsing the internet, I found out that the Xsens offerings are targeting various domains including entertainment (e.g., motion capture for movies), medical/health (e.g., gait analysis), sports and industrial/commercial (positioning and orientation systems). The Xsens website has a lot of very interesting case studies/examples of where its devices are being used. 

https://www.xsens.com/explore?filter=cases

The kit under review is the MTi-680-DK, which is the development kit for MTi-680 device. This particular device is from the 600 series of "MTi" devices from Xsens (Xsens MTi 600-series). The "8" in the series means this is the RTK variant from among the 600 series devices. The 600-series webpage states the following:

"The MTi 600-series is our most flexible industrial-grade MEMS-based orientation sensor. The products in this affordable series are lightweight and robust as well as cost-effective and easy to integrate. The series is highly flexible, with native CAN support, external or internal Global Navigation Satellite System (GNSS) receiver support and Real-Time Kinematic positioning (RTK). With this series, you can access multiple integration levels, as it includes Inertial Measurement Units (IMU), Vertical Reference Units (VRU), Attitude and Heading Reference System (AHRS) and Global Navigation Satellite System/Inertial Navigation System (INS/GNSS). The MTi 600-series offers full-featured sensor fusion algorithms with an easy-to-use open software development kit (SDK)."

In simpler words, and now focusing more on the MTi-680 device, here are the key takeaways about this device:

• It's a MEMS based device. (Not mechanical and not optical)
• It includes 3 axis accelerometers, 3 axis gyros, 3 axis magnetometers, a barometer and temperature sensor. All come factory calibrated.
• The MTi-680 is of INS/GNSS type, which means its features are a superset of IMU/VRU/AHRS devices.
• An external RTK GNSS receiver can be connected (internal in case of the rugged "G" variant) Within the GNSS devices of the 600 series, the MTi-680 has the best GNSS performance since it supports RTK corrections. Accuracies down to centimeter level are possible when receiving these corrections 
• Compared to the cheaper, more ubiquitous devices (e.g., the MPU6050), these devices have internal sensor fusion algorithms (think of advanced Kalman filters) that produce the more meaningful data (orientation, heading, position, etc.). Usually, it's the latter which is of actual interest in most applications and not as much the raw sensor data. That said, the individual (corrected) sensor data is made available too, should the user desire so.
• On top of it, the devices are packed with several very clever algorithms that can be optionally activated to give additional performance in specific use cases.
• The devices are small, lightweight and provide decent integration options in terms of interfaces such as UART, CAN, RS232. Various timing synchronization options are available via few configurable IO pins, so the user can, for example, synchronize the whole system together on one time base.
• The devices have an open interface, and an SDK is provided to enable easy integration into users' systems.

Prior experience in the relevant domain (INS/GNSS):

Before I start reviewing the MTi-680 module, I want to give the readers some idea of my own prior experience with Inertial/GNSS modules. I mention this because my prior knowledge in the domain is sure to influence the steepness of the learning curve for me and can be somewhat different for others. 

• At work, I have used inertial sensors in in-sea products where they are used in the navigation and positioning sub-systems. Most of my experience has been with sensors from PNI Corp and Analog Devices in this regard. I have also used accelerometers in seismic sensors as inclinometers with certain accuracy requirements. These included sensors from ST, AD, Kionix and few others. My work included evaluation/selection, writing embedded drivers, writing simple filtering/processing algorithms, test reports, etc.
• For my hobby work, I have worked with IMUs when building drones based on Ardupilot/Pixhawk as well as scratch-built autopilot hardware. I have also used them in my attempts to build brushless stabilized Gimbals using a variety of custom and off-the-shelf hardware. These sensors included devices from Analog Devices, ST and TDK/Invensense, and were mostly the cheaper variants.
• I have also worked with GPS devices, mainly from ublox, in various projects both at and outside work. I have also used RTK as a user quite extensively while working as a seismic field engineer a decade ago. These were almost exclusively (very expensive and big) Trimble devices. 
  
  

Brief Review of Similar/Comparable parts

I usually like to start with a very brief review of comparable devices available in the market since it helps to understand where the reviewed device finds its place amongst the various offerings in the market. I will mention a few companies that offer some similar products in this domain:

• VectorNav 
• PNI Corp (SeaTrax AHRS)
• Inertial Sense: (IMX-5-RTK series)
• Ceva DSP/Bosch (BNO055/BNO085) - fused outputs, cheaper but lower performance
• Septentrio (partnering with Analog Devices)
• ....and others

I am rather hesitant to use the words "similar" or "comparable" because I have learnt over time that when it comes to these Inertial/GNSS modules, the details (features, performance specifications) REALLY matter. As with the Xsens lineup, the devices offered by the various other companies can be categorized as raw sensors, IMUs (Inertial Measurement Unit), VRUs (Vertical Reference Unit), AHRS (Attitude & Heading Reference System), or INS/GNSS systems. (To read up on the differences between them, I will refer you to this page from Xsens) A fair comparison of any two devices will require that they both fall in the same category. Secondly, the price does not have a linear relation with the performance here. There is a saying "you pay 10 times for double the performance". This holds very true in this domain and made the comparison very tricky. The other major issue was that the prices for a lot of sensors/modules are not available on their websites and require filing a request for quote, which was a major hurdle for collecting this information. Lastly, different devices from various manufacturers can offer different special features/processing magic which further complicates any attempt to perform a good comparison.

Unboxing

The following blog post captured my unboxing experience and first impressions of the MTi-680-DK kit. Read the post for full details:

Xsens MTi-680-DK: Unboxing and First Impressions

Getting Started

The following blog post captured my out-of-box experience with the MTi-680-DK kit from installing the relevant software until getting the first data out of the device (A "hello-sensor", if I may?).

Xsens MTi-680-DK: Getting started

Performance Tests

My tests in this regard consisted majorly of experiments with the kit to understand the real-world performance of the device.  The specifications on device datasheets can be tricky to understand, so this was an attempt to better understand what those numbers meant in more easily-understandable terms,. This was to eventually help determine what use-cases one can actually use the device in (or not) based on obtained results. It was also done to verify some of the performance numbers claimed in the device specifications. I also explored the effects of using the various optional algorithms made available in the device on the performance obtained. In the process, I also discovered interesting insights into the behavior of the internal Kalman Filter.

In Part 1, I mainly experimented with roll/tilt calibration accuracy, magnetometer/heading consistency as well as heading drift performance when utilizing different device options.

Xsens MTi-680-DK: Experimenting with performance - Part 1

In Part 2, I focused mainly on the magnetometers, since they are usually some of the most troublesome sensors to work with. In this regard, I also explored how well the calibration application (Magnetic Field Mapper) performs under various (somewhat extreme) magnetic conditions, as well as performance of some of MTi's special algorithms in presence of magnetic distortions. I also looked at the various offline/online calibration options as well as the Magnetic Field Mapper SDK use cases.

 Xsens MTi-680-DK: Experimenting with performance - Part 2 

GNSS tests

The MTi-680 is an INS/GNSS kit. Keen readers will observe that I spent majority of my effort experimenting with features more relevant to the INS (Inertial Navigation System) part. This is somewhat true and comes from a bias in my own interests as well as the types of projects I have worked with (e.g., underwater robotics where GPS is not available, or gimbal systems where GPS is not relevant). That said, I actually did end up spending about a fortnight experimenting with the GPS features. Infact, after receiving and unboxing the kit I got somewhat obsessed with getting the RTK to work. It wasn't so hard to figure out, since I found several relevant articles in "base" (Xsens's knowledge-base articles). The main issue I encountered was that I needed RTCM corrections for RTK to work, broadcasted over the internet by some nearby NTRIP master "base station". After figuring out how to get the RTCM data to the MTi device in real-time (which is very straight forward if using MT-manager), I set out to find a nearby free NTRIP base station. This is where I hit a snag, whereby the closest free source I could find was >200 kilometers away. For reference, to get decent performance, you need NTRIP master within a 30km radius. When I tried using that particular station as my RTCM source, it made the GPS positioning worse than without it, which wasn't surprising.

After further digging, I found that setting up my own NTRIP master is actually not that complex, and I can set one up without any software cost and using one of the free NTRIP casting services (check out RTK2GO). However, you still need a GPS receiver that supports RTK. The ublox ZED-F9P on the MTi-680-DK is one of the supported devices, but you need two - on as base-station and one as the rover unit. For a moment I got excited when I saw the ublox NEO-M8P as another option, only to find out that both the GPS receivers I had lying around from some autopilots are all M8"N" variants, that don't support RTK. I will be writing a separate blog post with more details on this topic. Additionally, if I succeed in getting hold of another ZED-F9P or NEO-M8P device, then I can have my own NTRIP master, and that will definitely deserve a separate detailed blog post. I do wish the kit had come with one more ZED-F9P module (+antenna), so that I could have used that as my NTRIP base-station.

Documentation 

Good documentation is one of the most important things for any engineering device/kit, so naturally I have been paying special attention to this aspect over the past weeks. The documentation from Xsens can be accessed via the Xsens website ("Support" -> "Knowledge base") and is completely open, i.e., you do not require a customer account to access it. Same thing with the software downloads.

For the MTi devices, I would divide the available documentation into the following categories:

• MTi Product Documentation (https://mtidocs.xsens.com/home). This includes:
  • MTi Family reference manual -> Covers the whole MTi family 
  • Manuals for individual series (including 600 series). Further divided into:
    • Device Datasheet
    • Development Kit user manual
    • Hardware integration manual
  • MT Manager user manual -> Manual for the "MT manager" software application
  • Firmware updater user manual
  • Magnetic calibration Manual -> Full of good knowledge and very interesting to read.
  • Documentation for the MT low-level (binary) communication protocol
  • CAN protocol documentation (due to CAN packet structure and limitations, this can't be same as the protocol over UART)
• Video tutorials (https://tutorials.xsens.com/) -> Few but of good quality. Hoping to see more in future.
• "Base" articles -> These are short articles to explain various topics like algorithms, features, and many other topics that didn't make it to the Manuals (yet?). This also includes many articles on 3rd party integrations, for example how to use the MTi devices with your Arduino or Jetson devices. At 2-5 minutes required to read an article, I generally found these had a good balance between conveying the information while staying interesting by keeping it short.
• Forum posts  -> These are questions asked by different users. Anyone with a (free) account on the website can post questions and does not require a support contract or purchase verification (some manufacturers do that!). The questions get answered by people in the community as well as Xsens employees. You do not need to login to just view the posts.

I also found the following page which lists all the various pages relevant to the MTi devices. 

https://base.xsens.com/s/article/All-MTi-Related-Documentation-Links?language=en_US

This includes links to all the documentation, "base" knowledge base articles, software download pages, etc. I found that having all the relevant knowledge base articles listed down here was especially useful and helped me notice articles about technical details that I had not thought of, and hence wouldn't have searched for them myself. For example, I found an article about synchronization, which turned out to be very interesting. It was a topic I had not paid much attention to before. Over the weeks I ended up reading many articles and have learnt a lot of new and interesting things in the domain.

I like the way Xsens has make the documentation available. All the documentation is made available online, which means you will always have access to the most updated version of the documentation. On the other hand, if you prefer documentation in pdf format, then there is a way to get that as well. For example, I wanted to have documentation in Pdf format so I could read-through the manuals on my ebook reader. I found that you can download pdf version of the manuals directly from the online documentation main pages.

This saved my eyes many hours of extra screen exposure. The pdf files can also be very valuable if you are going to a field location with limited connectivity, for example. MT manager's "documentation" help also takes you to the online documentation.

It also appears that the pdf version is generated/updated frequently, as shown by the date on the pdf manual I downloaded. 

(This pdf file was downloaded on 1st October 2022)

I did some "spot checks" by comparing the pdf documents with the online documentation several times, and found that the information in both was the same, which was reassuring. I have to say, though, that the formatting appears much nicer on the web-pages as compared to the generated pdf manuals. Perhaps something that can be improved. I also found a few instances of the images from the web documentation not appearing in the generated pdf, for example as seen in the image below for the MTi Family Reference Manual.

Above: The pdf version doesn't display the image for the right-hand rule, while it is displayed fine in the online documentation. 

Another thing I noticed is that the pdf version loses the (very useful) hyperlinks compared to the online documentation, which is a very big time-saver in case of the latter. I have seen many other pdf manuals embedding the hyperlinks, so it should be doable. Perhaps something that can be improved in the way the pdf versions are generated.

Overall, as I mentioned, in my view this is a very good way to make documentation available in both web and downloadable pdf files, since the users can refer to online documentation for the latest version in normal cases and download pdfs for cases when offline use is needed.

One thing that I couldn't find in the documentation (MTi-600 series User Manual, MTi Family reference Manual) was the recommended torque for the mounting screws. Since the MT-680 casing is made of Industrial plastic, I think the recommended torque value MUST be given to avoid over-tightening the module.

Availability Of Design Resources: Let's look at the design resources (or design "collateral" as some would say) made available for the MTi-680 device by Xsens:

• The device datasheet is available, with details on the device performance, (electrical) specifications of the interface connector pins, device mechanical dimensions, mating connector part numbers, etc. 
• All devices have STEP files available for download inside "base". If you are not familiar with STEP files, this a common file format for (mechanical) CAD models and can be imported in all major CAD software. The STEP files are even available for the Dev boards, in case you need them. This should make integrating these devices in your mechanical assembly very convenient.
  
• The details relevant to various electrical connections on the Dev kit (MTi-680-DK) are available in the Dev kit manual, however, the dev Kit schematics are not provided (something I didn't like)
• The "MT SDK" is the provided SDK if you want to integrate the device in your own system. Examples code is provided in C++, C#, Matlab, python.
• The Xsens binary protocol to communicate with the devices is open and well documented in its own manual. This is very useful because even if you don't/can't use the SDK provided by Xsens for interfacing, you can construct the binary messages from scratch and use them directly from your microcontroller code, for example. If you go this route, also check out the "Data View" feature inside the MT Manager which will make your life much easier.
• The protocol for the CAN messaging is also described in detail. Xsens even provides a "CAN database" (.dbc) file to assist with interpretation of CAN messages using any of the freely available tools on the web.
• An SDK for the Magnetic Field Mapper (MFM) is also provided. I was able to compile and run the C# examples in a matter of minutes. However, from what I could see, currently dlls are only provided for x32 and x64 systems. 

Overall, I have found the documentation and design resources to be generally quite good. I have to mention that due to the huge amount of documentation and design resources available, and the road-test time limitations, I have not been able to go through all resource in full detail. I hope to continue covering more grounds in the coming months, as I integrate the device for some interesting hobby projects.

Device selection tool:

The MTi series lineup has several modules available, and for a new user it can be a lot of information to digest. I liked that Xsens has made available a simple web-based "tool" for the user to short-list/select the device(s) more suited to their use case by answering a few basic questions only. The options also have helpful tooltips in front of them to ease the selection process. It's simple, but I think it does the job well. 

https://www.xsens.com/mti-recommendation-tool

I tried the tool with a few different use cases in mind. The recommendations looked sensible. 

MTi-680 vs....cheaper devices?

The MTi-680 is an expensive device. Some people will be tempted to compare a device such as this with a cheap IMU sensor like the ubiquitous MPU6050 (or any similar commonly available 6/9 axis device) and ask "why can't I just use that device instead?". I want to briefly explain the differences:

1. Device calibration. No two sensors are built the same, thanks to manufacturing process variations. All sensors need calibration if you want to use them in applications that require high performance. The MTi-680 comes factory calibrated, which saves the users from building their own costly and complicated calibration setup. I recall reading in the documentation that each sensor is individually calibrated, including calibrating for variations with temperature This would actually make it a fairly long process to calibrate each sensor, in my experience. My guess is that the calibration cost accounts for a decent portion of the total device cost.
2. MPU6050 is an IMU, not an INS/GNSS device. Meaning, MPU6050 will output raw Accelerometer/Gyro (and magnetometer in case of some similar 9 axis modules) readings, but not the calibrated, sensor fused, Kalman Filtered state estimates (e.g., orientation estimates). Usually, the latter is what you actually need in most applications. Going from the raw sensor values to decent estimates of states requires implementing statistical filters (like the Kalman filter) and is not too straight-forward unless you are knowledgeable in the domain.
3. For navigation tasks, you might ask why we can't just use the output from a GPS device? 
   1. First of all, GPS will not give you orientation information (inclination angles, heading), but rather you will only give position information (Latitude, Longitude, altitude). For Inertial Navigation you need the orientation information as well, and even more so if there are brief moments of GPS outage.
   2. The MTi-680, when used with an external or internal GPS device, gives you "(sensor) fused" position outputs in addition to the orientation outputs. This makes the estimated position outputs more stable than the raw position data.
   3. GPS position output is usually limited to 25Hz maximum, and more commonly 10Hz or less. On the other hand, the position estimates coming from MTi-680's sensor fusion engine can go up to 400Hz. This higher rate comes not just from extrapolation but accounts for all the information received from the inertial sensors as well. This is especially useful when using the device in faster moving objects whereby 10Hz may not give good enough time-resolution.

MTi-680-DK: Things I liked

• The break-away USB-UART pcb module is a brilliant idea and I found it VERY useful in my testing. Infact, many of the tests that I performed with my device would not have been possible if this were not included or delayed by weeks if I had to build my own adapter.
• One thing that I really loved about the "MT Manager" application was that I could perform so many experiments using the device without even writing a single line of code. This was very useful because I wanted to better understand the behavior of the device in various situations and with various settings. This required logging various types of data with various settings, and usually for longer lengths of time. Afterwards I had to replay that data, export it out to an excel-readable format to process it further. All of this was such a breeze with the options available in the MT Manager.  
  
  
• I found small details in so many places within the software/interface which I found very thoughtful. For example, when you export the data to a text file the application also adds comments with the various settings that were used when acquiring the data. I didn't expect this and had planned to note down the settings for each experiment in a separate file. I was pleasantly surprised when I saw the relevant information in the exported file as comments. One less thing to do!
  
  
• I became a big fan of the "Device Data View" in MT Manager application. I initially discovered it via one of the tutorial videos on the Xsens tutorials page. Basically, it lets you Send and Receive data to/from the connected device. But sending data includes a neat mechanism to allow you to choose message types from a drop-down and compose the messages without even looking at the documentation (remember that the messages are in a binary format). The received messages area also decoded and displayed in real time. This makes the process of sending and receiving binary data to/from the device a breeze. This is a huge time saver! You can look at the details of this feature in this tutorial video.
  
  
  
• The device settings allow the user to set output data rates for individual types of data independently. For example, you can set the device to output gyro data at 400Hz, while outputting position data at 50Hz. Or vice versa. This makes the device very flexible in terms of getting all the needed data out at the required rates, while not burdening the communication interface with unnecessary data. This is much better than what I've seen on some other devices in the past whereby you could get everything at the same rate.
  
  
• I liked the fact that multiple "filters" (flavors of the Kalman filter) can be stored inside the device, and more importantly, the user can switch between them on the fly. I used a similar device from another manufacturer in the past, in which you needed to upload a different firmware file if you needed to use a different flavor of Kalman filter. MTi-680 can store up to 3 filters at a time. You have to decide which ones to keep on the device (using the MT Manager's Device Settings window), but you can switch between those 3 without needing to re-flash the firmware and the switching can be done via the communication protocol.
  
  
• I found a feature inside the device whereby it stores the World Magnetic Model inside the device itself and as the device location (and time) is updated, it will update the magnetic declination value to continue producing the true north heading. The location information can be automatically taken from the attached GNSS module or sent by the application if no GNSS module is attached. And since the magnetic declination drifts over time, it even accounts for it by using current time as the other input. For any other device I have worked with until now, the declination value had to be provided by the host system, which also necessitated a system to determine the current declination value first. 
  
  
• In terms of communication protocol, Xsens has gone for a common protocol that all its devices are compatible with. This is a very good approach since it means that as a user you don't need to continue to adapt your interfacing code over time when newer device versions are released. It also means that you can switch between the different variants in the lineup, based on needs, without having to change your interfacing code. For example, I can buy a MTi-680 during initial development when I am not sure about my exact needs, but later swap with, for instance, a MTi-200 module if all I need is a VRU in my final product, without having to rewrite my entire interfacing code.
  
  
• The recent worldwide chip short has made the prospect of not having to deal with part obsolescence very attractive. The user can buy the modules from Xsens, while leaving Xsens to handle component obsolescence. The interface will remain same.
  
  
• The Magnetic Calibration manual is very detailed. It was a very interesting read of around 36 pages. I not only found the information I was looking for, but I learn many things about the subject that I did not know before.
  
  
• The Magnetic Field Mapper and the calibration options in the device cover pretty much every real-world calibration scenario that I could think of. Frankly, the number of available options exceeded my initial expectations.
  
  
• I really loved the case studies page on the Xsens website (https://www.xsens.com/explore?filter=cases). There are a LOT of case studies on the page. Initially I went to the page looking for some case studies related to some projects I had in mind. However, I ended up spending many hours reading through the various case studies that were also NOT related to what I had initially gone looking for. This was good because I learnt of use-cases that I had never thought of before. 
  
  
• I liked the fact that the online documentation can also be downloaded as pdf, which made it much more convenient for me to read the documents on my e-paper tablet.
  
  
• I found that the video tutorials, although few, were good in content and quality. In-fact, I had initially intended to do a small "getting started" video but found that Xsens already had a good video on the tutorials page. Note that although the linked page has quite a few videos, when you narrow down to the MTi parts, you are left with a few videos only. Nevertheless, I did find that they covered quite a few topics, including some of the optional algorithms (AHS, Manual Gyro bias estimation, etc.) which were helpful to understand those.
  https://tutorials.xsens.com/
  
  
• "Base" (https://base.xsens.com/s/ism-landing-page) has a wealth of knowledge related to these devices! Over the past weeks I have spent hours going through the articles and forum posts and I learnt so many things there. Infact, I also found answers to some of the issues I encountered (e.g., not being able to detect device while trying the firmware upgrader initially) on base. I also liked the fact that most of the articles there are brief, and you learn something new with a few minutes of reading. As an example, I came across this article (https://base.xsens.com/s/article/Using-the-magnetic-norm-to-identify-magnetic-distortions) about identifying if magnetic distortions are present in the environment from the "Mag Norm" values. It even links further to another article that gives the formula of how the value is calculated. 
  
  
• During the course of the road-test, I had several interactions with the Xsens support team for various queries I had. I always received satisfactory answers in a prompt manner.  

I think the thing I like THE MOST about the MTi-680 is that it is so much flexible in usage. You can individually select which data to output (sensor data and/or final fused/filtered data), reporting interval for each data type (individually!), and even the formats (fixed points, floating points, etc.). I had never expected this level of flexibility from the device. For orientation, you can get the data out in Euler, Quaternions or rotation matrices. On top of that, you have options to run various filters, 3 of which can be stored on the device and switched-between without having to re-flash the firmware with a computer. Additionally, you get to use various special algorithms that can improve the performance in particular use cases. Even the World Magnetic Model is stored inside the device so you don't have to calculate and feed the magnetic declination values from your own source to get north-referenced outputs. There is seriously a lot going on in this tiny little device.

 
Above: "Device settings" of the UART interface showing the flexibility in specifying output data, reporting rates and formats - all individually!

MTi-680-DK: Things I didn't like/suggestions for improvement/Wish-List

• The thing on the top of my wish-list for this dev-kit is a secondary set of RTK-capable GPS module (+antenna) that can be used as a RTK base station. The fact that for good RTK performance you need a NTRIP master within a 30km radius means the chances of finding a free NTRIP server within a 30km radius is very low. Even the city I am in, despite being a major city, did not have a free NTRIP master and the closest one I could find was >200km away. For a kit advertised as an RTK-enabled kit, I think there is much value in adding some hardware to enable evaluation with a self-hosted NTRIP master.
  
  
• The development kit came with very fragile friction-fit plastic PCB standoffs, which is not something I expected from a premium kit like this. One of the standoffs was either missing or fell off within the first 10 minutes. This caused some issues in keeping the board flat on the table subsequently. I had some other PCB standoffs on hand, but they were all made of ferrous materials. It would be better to instead include Nylon or brass standoffs (nut& bolt type) with the kit.
  
  
• I found a mechanical fit/tolerance issue when connecting the provided ribbon cable connector to the device. The connector on the device sits slightly deeper than it should, relative to the device casing. The result is that the mating connector doesn't latch to the device connector properly. In the picture below the connector is pressed all the way down and it can be seen that the latches are still not active. Could be a tolerance issue in the manufacturing process or design.
  
  
  
• The naming of some buttons in the MT Manager interface is not very intuitive. For example, in the "Device Settings" window, the "Revert" button resets the device back to factory defaults. A clearer name would be better, for example "Restore factory Defaults"? The other issue is that when you click the "Revert" button, the MT manager does not ask for a confirmation before executing a factory reset. In-fact, the first time I clicked the "Revert" button was unintentional, and I ended up losing all my settings. There should be a warning/confirmation dialog box before restoring the device to factory defaults. Note that this also restores any magnetic calibration back to factory defaults.
  
  
• The "Position View" inside the MT Manager plots the GPS coordinates coming from the device. Scales are displayed on the X and Y axes in degrees Latitude/Longitude. There is no scale correlating those units to ground distances in meters. During my experimentation with the GPS position output, I had had to find formulas to convert changes in latitude/longitude to on-ground distance in meters, and then used an excel sheet to convert the obtained values into distances in meters. It would make the life of users much easier if a distance scale in meters is displayed in the Position View. This would give users an idea of the real-world "scale" of the readings. Moreover, having an option to switch-on a google-earth background would be very valuable. During my testing, I found myself copy-pasting the coordinates to google maps to check obtained positions on map.
  
  
• I had some issues with the software applications. For example, the "Magnetic Field Mapper (MFM)" stopped opening for me at some point. I had to reinstall the MT software package to get it back. 
  
  
• Specifying the mounting orientation can be made simpler, I think. Especially when you want to maintain the level calibrations with respect to the device body. I encountered this issue when experimenting for one of my blog posts, and it wasn't immediately clear how to do it despite reading the relevant article. I finally managed to figure it out and also got confirmation from Xsens about it. Currently the user needs to manipulate the "RotSensor" matrix manually. While it's good to have that available for the more advanced users, I think it's better to also add a simpler interface in MT Manager, for the less advanced users. As an example, another device I have used in the past gives the following in its user interface. 
  
  I have seen similar drop-down options in another device's interface also and found it very convenient.
  
  
• I wish the MT manager provides a bigger variety of "filters" in future. Currently there are 3 filters available in the "MT Manager" and they might not fit everyone's use case. For example, in my experiments I noticed that if accurate north-referenced heading is critical to the application, then the best performance was obtained by using the "26.2 GeneralMag_RTK" filter. However, the weightage given to the magnetometer data was small. This was perhaps done to give better immunity from magnetic disturbances (running motors, etc.). However, I could be using it in an application where there is no magnetic interference nearby and so I want to give more weightage to the magnetometer data to track the magnetic north more closely. Alternatively, or in addition, if there is a way to tune some parameters of the filters, I think it will enable better usage of the modules in many more situations.
  
  
• I would like to see more of the information in the "Base" articles making its way to the main documentation/manuals. When customers ask questions, it's usually because they couldn't find that particular information in the main documentation or it was not too clear. It would make sense to gradually use this as a feedback mechanism to add more details in the main documentation. There were instances where I expected to find something in the main manuals but didn't, and later found the information in some base articles. 
  
  
• Although the Development Kit documentation gives good detail on the functions of different connectors on the kit, one thing I dearly missed was the schematics. Descriptions are good, but there is simply no substitute for development board schematics. I am assuming the main business for Xsens are the devices, and not their development boards, so I don't see why the schematics of the development boards should not be made available. For a design engineer incorporating the module in their design, having the schematics available gives more confidence on their own design and most will just copy-paste some part of the design to their own board when using same interfaces. I highly suggest that these are made available in the documentation package. 

Final Words

Before starting to use the MTi-680 review, my initial expectation was that I will be able to finish testing the various aspects of the device in a few weeks. It took a lot longer, and I still can't claim I have managed to cover all aspects/features of the device yet. For many development kits, this happens because of how difficult it is to set up and get started. It was quite the opposite with the MTi-680. I experienced one of the smoothest out-of-box experiences (save a few minor issues), decent documentation and generally very intuitive applications/user interfaces. I had several experiments planned to get a firsts-hand feel of how good the actual performance is, and I started with the expectation of having to spend considerable amount of time preparing (e.g., writing scripts) for the experiments. However, once I started with the experiments, I realized that the Xsens software allowed me to get the needed information out of the devices without writing my own code. This really helped me focus on the experiments themselves and understanding the data/results and made the experience very pleasant!

So why did it take me more time than my expectation? Interestingly, it was because I had under-estimated how "loaded" the device is in terms of features. Once I started reading up the documentation and experimenting the device, I realized that there were so many things that were going on inside the tiny device that reading about those things in the manuals and "base" articles and trying them on the device took a lot of time. And I still feel I have not explored all the aspects of the device completely. That said, and depending on your use-case, as a user you may not necessarily need to know everything, rather just the relevant subset. In my case, since I wanted to cover as much ground as I could manage, there was plenty to keep my occupied for weeks. I am still amazed at how many features are packed inside this tiny little device. It's a seriously good piece of engineering!

My major gripe with the device, before I received it, was the high price tag. Personally, I try to limit my road-testing to products that I am going to use myself in future projects. This way I don't gather paperweights, and it also helps justify the long hours and effort spent in the review process. The MTi-680 was a rather interesting case, since it is a rather expensive part, at-least for use in hobby projects, and frankly I was a little bummed about this aspect initially. "Why couldn't Xsens make it available at a cheaper price", I asked myself. However, the more I learnt the details of this device, whether from reading documentation or from my own experimentation, the more I started to come to terms with the pricing. I have used some Inertial devices for hobby as well as serious work projects in the past, so I had some idea of performance vs pricing. I began to realize that building a device like this, with these many features inside, is no small task. In the past I have read about various techniques used to improve the performance of IMU/INS devices, usually in published research papers. While some of the other devices I used in the past had a subset (or none) of those advanced features, I feel the Xsens device has the superset of all of those techniques/features built inside. And that has changed my view about the price. If and when I need the performance, I can save myself the cost hiring several PhDs in the domain and months/years of development effort and instead simply use one of these modules in the product and focus more on the value-added features of my end product. Suddenly it doesn't feel that expensive anymore.

Bottomline - Would I recommend this product for your next project?

In summary, on one side, at ~1700$+ a piece, this is most certainly not a cheap device. On the other side, it comes factory calibrated, gives very solid performance out of the box and is very flexible in terms of how it can be used. It's also backed by comprehensive documentation and a responsive support team.

With those things in mind, let's look at a few scenarios:

• If you are a hobbyist on (the usual) tight budget or a student without a sponsorship for your project, then this device is most certainly out of your budget range.
• If you are a student with a sponsored project, then I would definitely recommend considering the MTi. Even if you plan to develop your own Sensor fusion algorithms, the MTi will give you a very solid reference device to compare with. It will also enable you to start developing algorithms on your computer (e.g., using python or C++) in a matter of minutes, not days or weeks. Also, since the sensors are calibrated, you can start focusing on the higher-level algorithms/logic right away. Personally, I find this a huge plus.
• If you are an engineer building a commercial product that needs navigation functionality, then it depends on whether your product can afford the additional BOM cost or not. However, even if you can't use it in the final product, there is still a good case for using it in the development stage for reasons discussed in the previous point.
• If you are developing a commercial product that needs a high-performance INS/GNSS module for your product (usually implying the application can afford the added cost), then I would absolutely recommend this product. This will surely save you a lot of development cost and time, and your team can instead focus on the valued-addition aspects of your product. It will also save you from having to maintain the INS/GNSS technology and dealing with obsolescence issues over time.

Note that the MTi-680 is the most expensive variant in the MTi lineup, being INS/GNSS devices. There are other device offerings with a subset of features (IMU / VRU / AHRS) that have lower prices. One of those might make a better fit for your use-case.

I am very grateful to Xsens and Element14 for providing me this opportunity to learn and experiment with this nice kit. The kit will definitely see itself getting used in many of my technical adventures in the coming times.