RoadTest: Xsens Position and Orientation Sensing GNSS/INS Dev Kit
Author: Kilohercas
Creation date:
Evaluation Type: Evaluation Boards
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?: This information will be posted in review part
What were the biggest problems encountered?: So far none !
Detailed Review:
Hello,
It’s been a long time since I got the XSENS MTI 680 RTK module, so I will start my journey exploring the capabilities of this device. Just as a quick note, this device was sent before my month-long vacation across the Balkans and Turkey by motorcycle, so this review will take some time to complete. As usual, nearly no free time after work and my personal projects.
This device came in a very nice box, but if you look at the price point, you will understand why. The MTi-680 RTK GNSS/INS Development Kit cost around 1500-1900€ and it is a very nice bit of kit !
I am most interested in 3 aspects of this device. Gyroscope performance, accelerometer performance and fusion with GNSS to get ultra precise location of this device when used with dual band dual feed RHCP antenna. And by using RTK, it is possible to get down to 1cm, but for that base station is needed, so you can compensate for ionospheric delays and other instabilities
Let’s talk about gyroscopes. For that I need to put you into perspective how this device compares with consumer grade gyroscopes from Bosh, ST, and Analog devices..
Units |
|||||||
Full range |
°/s |
2000 |
2000 |
2000 |
1000 |
4000 |
2000 |
Bias stability |
°/s |
0.002 |
1 |
1 |
0.00077 |
2 |
0.000001 |
Bandwidth (-3dB) |
Hz |
520Hz |
256Hz |
6.4kHz |
400Hz |
7.68kHz |
~1000 |
Noise density |
°/s/√H |
0.007 |
0.024 |
0.007 |
0.00357 |
0.07 |
Can’t find |
Cost |
€ |
1600 |
2 |
2.5 |
1769 |
5 |
>30000 |
As you can see, you mostly pay for run bias instability, or in other words, if you rely only on gyroscope, and integrate steady state angle at output rate, you can drift by as much as 1 degree in a second, while mechanical or FOG gyroscopes will drift same amount in 1 month
Accelerometer is the second most important part for this IMU (I think). I would imagine that fusing accelerometer data with GNSS data could provide very stable and not jumpy location data, but this needs to be tested. As with gyroscope, here are few honorable comparisons between different producers:
Units |
|||||
Full range |
G |
±10 |
±16 |
±16 |
±40 |
Stability |
μg |
10 |
>60 |
>60 |
>20 |
Bandwidth |
Hz |
500 |
7680 |
1677 |
2400 |
Noise density |
μg/√Hz |
60 |
30 |
180 |
75 |
From this it does not look that MTI-680 uses something very special, maybe they do some compensation or sample at a higher rate and use filters to reduce noise. In GNSS fusion demo it will be interesting, how much better data will be provided with the MTi-680 and similar receiver without dead reckoning capability.
This is the best part so far. Connection and data extraction from MTI-680 was extremely easy to do. In less than 30 min without reading any documentation I was able to figure out how to use it.
First, we need to download XSense MT Manager to configure UART CANBUS. This we can do by downloading software.
After this we need to configure CANBUS speed in main setup:
Lastly, we need to configure what we want to see on CANbus and how frequent it is. That is nice that they use different canbus ID”s for different measurement.
After this all you have to do is apply you configuration, and module will be reconfigured in few seconds .Now, you can see CANBUS traffic on CAN_P and CAN_N ( it should be named H and L , but ok ) Here are some waveforms captured with differential probe:
And this is how much code I need to capture data to STM32H7 after configuration in STM32CubeMX ( I am using high performance STM32H743XI).
Now to get data into variables we need to open MT CAN Protocol Documentation to see how they are placed inside packets. And for me it was was few minutes of coding to get most important data converted into microcontroller variables
float Temperature = 0.0f;
float BaroPressure = 0.0f;
int16_t MagX = 0,MagY = 0,MagZ= 0;
int16_t AccX = 0,AccY = 0,AccZ= 0;
int16_t Roll = 0,Pitch= 0,Yaw = 0;
int16_t Q1 = 0,Q2 = 0,Q3 = 0,Q4 = 0;
volatile void HAL_FDCAN_RxFifo0Callback(FDCAN_HandleTypeDef *hfdcan, uint32_t RxFifo0ITs)
{
RX++;
LL_GPIO_TogglePin(LED1_GPIO_Port, LED1_Pin);
if((RxFifo0ITs & FDCAN_IT_RX_FIFO0_NEW_MESSAGE) != RESET)
{
if (HAL_FDCAN_GetRxMessage(hfdcan, FDCAN_RX_FIFO0, &RxHeader, RxData) != HAL_OK)
{
}
if(RxHeader.Identifier==0x50)
{
Roll = ((int16_t)RxData[0]<<8)+((int16_t)RxData[1]);
Pitch =((int16_t)RxData[2]<<8)+((int16_t)RxData[3]);
Yaw = ((int16_t)RxData[4]<<8)+((int16_t)RxData[5]);
}
if(RxHeader.Identifier==0x51)
{
Q1 = ((int16_t)RxData[0]<<8)+((int16_t)RxData[1]);
Q2 = ((int16_t)RxData[2]<<8)+((int16_t)RxData[3]);
Q3 = ((int16_t)RxData[4]<<8)+((int16_t)RxData[5]);
Q4 = ((int16_t)RxData[6]<<8)+((int16_t)RxData[7]);
}
if(RxHeader.Identifier==0x52)
{
Temperature = (float)(((RxData[0]<<8) + RxData[1]))*0.0039f;
}
if(RxHeader.Identifier==0x53)
{
BaroPressure = ((float)((uint32_t)RxData[0]<<24)+((uint32_t)RxData[1]<<16)+((uint32_t)RxData[2]<<8)+((uint32_t)RxData[3]));
}
if(RxHeader.Identifier==0x54)
{
MagX = ((int16_t)RxData[0]<<8)+((int16_t)RxData[1]);
MagY = ((int16_t)RxData[2]<<8)+((int16_t)RxData[3]);
MagZ = ((int16_t)RxData[4]<<8)+((int16_t)RxData[5]);
}
if(RxHeader.Identifier==0x55)
{
AccX = ((int16_t)RxData[0]<<8)+((int16_t)RxData[1]);
AccY = ((int16_t)RxData[2]<<8)+((int16_t)RxData[3]);
AccZ = ((int16_t)RxData[4]<<8)+((int16_t)RxData[5]);
}
if (HAL_FDCAN_ActivateNotification(hfdcan, FDCAN_IT_RX_FIFO0_NEW_MESSAGE, 0) != HAL_OK)
{
//Error_Handler();
}
}
}
Next step, will write application from windows side, that will read data over SPI from FPGA, and STM32H7 will upload data to FPGA , and use it as a FIFO.
To be Continued….