1 | initial version |

For any given measurement, there are two covariance matrices at play:

- The state's covariance matrix
- The measurement's covariance matrix

The one that concerns me in your case is your state covariance. You can set the initial value for this matrix using the `initial_estimate_covariance`

parameter. Here's the rule you should follow: if you *are* measuring a variable, make the diagonal value in `initial_estimate_covariance`

**larger** than that measurement's covariance. So, for example, if your measurement's covariace value for the variable in question is 1e-6, make the `initial_estimate_covariance`

diagonal value 1e-3 or something. This will speed up convergence. If you are *not* measuring a given variable (e.g., roll), make the diagonal value in `initial_estimate_covariance`

small (but never zero).

2 | No.2 Revision |

For any given measurement, there are two covariance matrices at play:

- The state's covariance matrix
- The measurement's covariance matrix

The one that concerns me in your case is your state covariance. You can set the initial value for this matrix using the `initial_estimate_covariance`

parameter. Here's the rule you should follow: if you *are* measuring a variable, make the diagonal value in `initial_estimate_covariance`

**larger** than that measurement's covariance. So, for example, if your measurement's covariace value for the variable in question is 1e-6, make the `initial_estimate_covariance`

diagonal value 1e-3 or something. This will speed up convergence. If you are *not* measuring a given variable (e.g., roll), make the diagonal value in `initial_estimate_covariance`

small (but never zero).

**EDIT 1**

It's hard to tell with the time scale what the lag is between the `amcl`

yaw and the `robot_localization`

yaw. For your plots, you might try (a) zooming in a bit more, and (b) subtracting the first time stamp from *one* of the data sources from all the timestamps from all sources so that we can see the time in the X axis better.

Also, can you turn OFF the yaw velocity from the wheel encoders in your second r_l config? I want to see the delay when you only have one sensor input.

Also, try increasing the `process_noise_covariance`

for yaw. It will make the error in the state estimate grow faster, which will in turn cause it to trust your measurements more.

Also also, you might want to try the `transform_time_offset`

parameter. I believe amcl future-dates its *map*->*odom* transform (with a default value of 0.1 seconds), so it may be worth doing the same.

3 | No.3 Revision |

For any given measurement, there are two covariance matrices at play:

- The state's covariance matrix
- The measurement's covariance matrix

The one that concerns me in your case is your state covariance. You can set the initial value for this matrix using the `initial_estimate_covariance`

parameter. Here's the rule you should follow: if you *are* measuring a variable, make the diagonal value in `initial_estimate_covariance`

**larger** than that measurement's covariance. So, for example, if your measurement's covariace value for the variable in question is 1e-6, make the `initial_estimate_covariance`

diagonal value 1e-3 or something. This will speed up convergence. If you are *not* measuring a given variable (e.g., roll), make the diagonal value in `initial_estimate_covariance`

small (but never zero).

**EDIT 1**

It's hard to tell with the time scale what the lag is between the `amcl`

yaw and the `robot_localization`

yaw. For your plots, you might try (a) zooming in a bit more, and (b) subtracting the first time stamp from *one* of the data sources from all the timestamps from all sources so that we can see the time in the X axis better.

Also, can you turn OFF the yaw velocity from the wheel encoders in your second r_l config? I want to see the delay when you only have one sensor input.

Also, try increasing the `process_noise_covariance`

for yaw. It will make the error in the state estimate grow faster, which will in turn cause it to trust your measurements more.

Also also, you might want to try the `transform_time_offset`

parameter. I believe amcl future-dates its *map*->*odom* transform (with a default value of 0.1 seconds), so it may be worth doing the same.

**EDIT 2**

I'm not convinced you don't have another problem with transforms. If you are just fusing the pose data from `amcl`

, then the two plots should be *much* closer to one another. In what frame is the `amcl`

data published? Is `amcl`

also publishing the *map*->*odom_combined* transform?

ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.