0
$\begingroup$

Rosanswers logo

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: https://drive.google.com/file/d/1EUJ7-FQFNrMB1Ql2whuho98WarzGq5hk/view?usp=sharing

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.

Thank


Originally posted by elgarbe on ROS Answers with karma: 106 on 2021-08-25

Post score: 0


Original comments

Comment by elgarbe on 2021-08-25:
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: https://drive.google.com/file/d/18byyaNkBzus0YfesBCiqg-11H4ycGBnT/view?usp=sharing

Comment by Fetullah Atas on 2021-08-26:
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

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by Tom Moore with karma: 13689 on 2021-12-15

This answer was ACCEPTED on the original site

Post score: 1

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.