ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

robot_localization perform worst just adding magnetometer to imu_filter_madgwick

asked 2021-08-25 20:50:48 -0500

elgarbe gravatar image

updated 2021-08-26 10:53:05 -0500

Hi, I'm trying to find some robot_localization issue on my unmanned surface vessel. So I've started with the simplest case: integrating just the IMU x and y acceleration on a table (I'm mean, a static test) I'm using an ICM20602 and published data @100Hz using rosserial to raspberry pi 3b+. In the Pi I have a robot_localization ekf node, some static tf and imu_filter_madgwick. imu_filter output is on /chori/imu/data topic. I've recorded two bagfile, one setting (param name="~use_mag" value="true") and another with param name="~use_mag" value="false"

In the first case, position output from RL increased very fast. In the second case, position output increase slowly, as I expected. I can't find any difference on linear acceleration output from imu_filter with and without "use_mag" parameter equal to "true" or "false".

launch, config and bag files:

EDIT: I'm trying to get position/velocity of my unmanned surface vessel. I have RTK GPS position and velocity in order to correct unbounded errors from the IMU. But on my field test I've noticed some extrange behavior between 2 GPS measurements. That is when the filter is using the IMU. So, as I said, I decide to make some static test using just the IMU (first) to see if I can find some issue. In this test I found that fusing just accelorometer data from imu_filter with and without magnetometer enabled make RL EKF perform really bad. I know that I will have unbounded position error, but with magnetometer enabled the error grows very fast compared with magnetometer disabled. My question is why?

EDIT2: Just to clarify a little the test. I have IMU data (raw accelerometer, gyroscope and magnetometer) coming in to two imu_filter_madgwick instances. One of them have use_mag=true ans the other =false. Each output is used for two instance of RL ekf filter. Each one is configured to just fuse acceleration data, and working on 2D mode: imu0: chori/imu/data_mag imu0_config: [false, false, false, # x, y, z, false, false, false, # roll, pitch, yaw false, false, false, # vx, vy, vz false, false, false, # vroll, vpitch, vyaw true, true, false] # ax, ay, az I expect that velocity and position output growth unbounded. But as I'm making an static test I expect the output increase "slowly".

image description

This is the X acceleration output of each imu_filter. As you can see both of them are equal. The same is for Y and Z axis.

Then thing is that RL output increase faster on imu_filter instance with use_mag=true:

image description

And as you can see, in 10 second it accumulate 2mts of error, wich is a lot compared with a couple of centimeter on the RL with acceleration data coming from imu_filter instance with use_mag=false.


edit retag flag offensive close merge delete


For a better visualization, here launch, config and bag files of two instance of imu_filter and RL running at the same time, with and wo magnetometer:

elgarbe gravatar image elgarbe  ( 2021-08-25 21:37:17 -0500 )edit

What exactly do you want to measure from IMU ? Note that IMU alone will be very unreliable to measure linear positions, it will keep accumulating error constantly, you need to provide something else besides, wheel odometry or another source of odometry

Fetullah Atas gravatar image Fetullah Atas  ( 2021-08-26 01:29:50 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2021-12-15 02:37:07 -0500

Tom Moore gravatar image

The EKF is producing a state estimate that comprises 15 dimensions. When you only measure a subset of them, the covariance in the dimensions that are not measured will explode. The filter's behaviour in this case will be highly unpredictable.

You need to make sure that you are measuring:

Absolute position (all three dimensions) _or_ velocity. The latter will result in boundless error growth, but the filter will behave. Absolute orientation (all three dimensions) _or_ velocity. As above.

Secondly, I would expect that fusing accelerometer data only will definitely result in a runaway state estimate, even if you have the rest of it configured correctly.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2021-08-25 20:50:48 -0500

Seen: 253 times

Last updated: Dec 15 '21