yaw angle change even the IMU device not move

[diennv]

Hi,
I am using Dev. Board(Mti-670).
I attached the KIT on the top of my car and run IMU node. ("roslaunch xsens_mti_driver display.launch") in ROS.
In initial time, the orientation of device almost did not change when the car stop. After the car run for a while, the yaw angle always change even the car stop.
Could you give some available reasons for that?

Thanks.

[Steven-GH]

Hello @diennv,

We have created a list of possible causes for this on our knowledge base: https://xsenstechnologies.force.com/knowledgebase/s/article/Reasons-why-the-heading-yaw-is-not-stable-or-incorrect-1605869709245?language=en_US

Could you have a look at this, especially the last section (GNSS/INS specific)? Which filter profile are you currently using?

[diennv]

Hi Steven, Thank you for your quick reply. We started to use IMU for robot localization. MTi-670 (GNSS/INS) is our first experiment with IMU, therefore, there were many mistakes and confusion , and many questions also :) Before, we used only IMU without GNSS enabled because we thought that the on-board GPS is low accuracy. We achieved linear acceleration and angular velocity to calculate quateration and then achieve heading angle (we dont know which frame does it reference). We want to use this heading angle to fuse with our external GPS data. However, it had the spinning issue as I mentioned. After verify with your answer, we connected and enabled on-board GPS, Currently, we are using the filter profile like below: --------------------------------------------------------------------------------- /imu/data /imu/mag --- header: seq: 1347 stamp: secs: 1627030163 nsecs: 152378247 frame_id: "imu_link" orientation: x: 0.0197074244843 y: 0.0182922315108 z: -0.137389630893 w: 0.990152059539 orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] angular_velocity: x: 0.00204220414162 y: -0.00316649745218 z: 0.0152803957462 angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] linear_acceleration: x: -0.209333747625 y: 0.399170994759 z: 9.84227657318 linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ we saw that the heading angle (achieved from orientation directly is much more stable, and used magnetic North as a reference). BTW, i had two questions. If using this IMU for indoor application (loss GPS signal), which direction does the heading angle reference ? Second, can we connect our external GPS to the IMU device ? (our external GPS is higher accuracy). If yes, is there any public guide for that? Sorry if my question is stupid but we want to understand about IMU for future development. Thanks you so much, Vào Th 6, 23 thg 7, 2021 vào lúc 16:19 StevenXsens < ***@***.***> đã viết:

…

Hello @diennv <https://github.com/diennv>, We have created a list of possible causes for this on our knowledge base: https://xsenstechnologies.force.com/knowledgebase/s/article/Reasons-why-the-heading-yaw-is-not-stable-or-incorrect-1605869709245?language=en_US Could you have a look at this, especially the last section (GNSS/INS specific)? Which filter profile are you currently using? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3XMZ74IXXKAGVRKSBXK4DTZEJZFANCNFSM5A3KOYKA> .

[Steven-GH]

Hello @diennv,

Concerning heading output during GNSS outages, there are two scenarios:

• With General(NoBaro) filter profile, the heading will be unreferenced (initialized at 0 deg) when the MTi powers up. As soon as GNSS data is received and if the MTi is moving, the heading will automatically become globally referenced (with respect to East). If a GNSS outage happens after that, the MTi will keep estimating its heading with respect to the global frame.
• With GeneralMag filter profile, the heading will always be globally referenced (with respect to East).

Yes, you can connect a different external GNSS receiver to your MTi-670. It supports the UBX (u-blox) or NMEA protocol. More information can be found in the below documentation chapters:
https://mtidocs.xsens.com/signal-processing-and-algorithms$gnss-input
https://mtidocs.xsens.com/interfaces-2$gnss-receiver-interface

[diennv]

Hi Steven, Thank you for your guide. First, we tested the GNSS/INS fusion solution. It seemed to work. The shape of the road waypoint was reasonable. However, the position of the waypoint was shifted compared with our GNSS data (with RTK server support). We tried to connect our GNSS (with RTK server supported) data with Mti-670 board via the RS232 interface. We set GNSS output nmea formats: GPA, RTC..., with 4Hz, baudrate 115200. We use MT manager to visualize the output of xsens board. However, there was no GPS data at all. It seems to have problems with physical settings or connection. I tried to search but there are no examples of connecting xsens development boards with external GNSS receivers. Could you guess where our problem is? Thank you so much, Vào Th 2, 26 thg 7, 2021 vào lúc 15:58 StevenXsens < ***@***.***> đã viết:

…

Hello @diennv <https://github.com/diennv>, Concerning heading output during GNSS outages, there are two scenarios: - With General(NoBaro) filter profile, the heading will be unreferenced (initialized at 0 deg) when the MTi powers up. As soon as GNSS data is received and if the MTi is moving, the heading will automatically become globally referenced (with respect to East). If a GNSS outage happens after that, the MTi will keep estimating its heading with respect to the global frame. - With GeneralMag filter profile, the heading will always be globally referenced (with respect to East). Yes, you can connect a different external GNSS receiver to your MTi-670. It supports the UBX (u-blox) or NMEA protocol. More information can be found in the below documentation chapters: https://mtidocs.xsens.com/signal-processing-and-algorithms$gnss-input https://mtidocs.xsens.com/interfaces-2$gnss-receiver-interface — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3XMZ4K4WX7QPLNXT3JS4DTZUBSRANCNFSM5A3KOYKA> .

[Steven-GH]

Hello @diennv,

The hardware-wise connections can be found here:
https://mtidocs.xsens.com/interfaces-2$gnss-receiver-interface

And the software configuration can be found here:
https://mtidocs.xsens.com/signal-processing-and-algorithms$gnss-input

Does your GNSS receiver output GGA, GST, RMC and GSA (all are required) with the same Talker ID (GN, GP or GL)? You will also need to configure your device to receive NMEA messages using the SetGnssReceiverSettings message.

Finally, please note that the MTi-670 is designed for use with non-RTK GNSS receiver. Connecting RTK GNSS receivers is possible, and the MTi-670 can use the data for its GNSS/INS fusion, but the sensor-fused position output may not be centimeter-accurate.

[diennv]

Hi Steven, Yes, we configured GPS receiver output GGA, GST, RMC, GSA with same Talker ID. Our GPS receiver is: MRP2000 with RTK server. ( http://www.omasurvey.kr/mall/m_mall_detail.php?ps_ctid=02000000&ps_goid=214 ). Today, we tested but not working yet. We may missing PPS signal. Our GPS output interface is RS232 interface. How to get PPS from GPS device? Thanks. Vào Th 2, 2 thg 8, 2021 vào lúc 21:07 StevenXsens < ***@***.***> đã viết:

…

Hello @diennv <https://github.com/diennv>, The hardware-wise connections can be found here: https://mtidocs.xsens.com/interfaces-2$gnss-receiver-interface And the software configuration can be found here: https://mtidocs.xsens.com/signal-processing-and-algorithms$gnss-input Does your GNSS receiver output GGA, GST, RMC and GSA (all are required) with the same Talker ID (GN, GP or GL)? You will also need to configure your device to receive NMEA messages using the SetGnssReceiverSettings message. Finally, please note that the MTi-670 is designed for use with non-RTK GNSS receiver. Connecting RTK GNSS receivers is possible, and the MTi-670 can use the data for its GNSS/INS fusion, but the sensor-fused position output may not be centimeter-accurate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3XMZYXYP2NQCAE36UNTXTT22C7NANCNFSM5A3KOYKA> .

[Steven-GH]

Hi @diennv,

What is the SetGnssReceiverSettings message you have sent to the MTi? And which Talker ID does your GPS receiver use?

An RS232 interface is perfect. The PPS signal is not a hard requirement; it is only used for clock synchronization purposes.

[diennv]

Hi Steven, Yes. I configured the GPS receiver output rate to be 4 Hz. I connected our GPS device to IMU as shown in an attached file. Also, GPS output messages, IMU settings, results data are attached in mail. Pls check it and let me know your opinions. Thanks. Vào Th 4, 4 thg 8, 2021 vào lúc 16:53 StevenXsens < ***@***.***> đã viết:

…

Hi @diennv <https://github.com/diennv>, What is the output rate of your GPS receiver? Can you set it to 4 Hz? And what is the SetGnssReceiverSettings message you have sent to the MTi? An RS232 interface is perfect. The PPS signal is not a hard requirement; it is only used for clock synchronization purposes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3XMZ7WSNJCORXJXPFI2BTT3DWVHANCNFSM5A3KOYKA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[Steven-GH]

Hi @diennv,

Sorry, but I can't seem to access the attachments you sent... Could you perhaps send your e-mail to support@xsens.com? I will make sure that I or a local product specialist will support you further with this.

[diennv]

Yes. I sent. Pls check it. Thanks. Vào 04:49 PM, T.5, 5 Th8, 2021 StevenXsens ***@***.***> đã viết:

…

Hi @diennv <https://github.com/diennv>, Sorry, but I can't seem to access the attachments you sent... Could you perhaps send your e-mail to ***@***.***? I will make sure that I or a local product specialist will support you further with this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3XMZ6C5FIE6VJZYK5KLPTT3I7AXANCNFSM5A3KOYKA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .