Revision history [back]

1. Why do you say (x,y) is calculated using yaw? It should be the other way around - encoder counts from each wheel input into a formula that takes wheel base and wheel radius into account https://www.cs.princeton.edu/courses/archive/fall11/cos495/COS495-Lecture5-Odometry.pdf. Assuming a skid-steer platform here. You shouldn't do anything to the wheel odometry like resetting it - you'll just be building up error that way. It would be like running a second EKF to process the results of the first one - no benefits.

2. What is the yaw reading from the IMU when you start your robot, is it 0? Where does the robot actually point in relation to the starting point when odometry is reading 45 (i.e. how close is that reading to the truth)? Read http://docs.ros.org/melodic/api/robot_localization/html/state_estimation_nodes.html#sensor-differential "This setting is especially useful if your robot has two sources of absolute pose information, e.g., yaw measurements from odometry and an IMU". IMU orientation is usually absolute.

3. It depends on what you're trying to achieve. In a nutshell, the filter will not correct (x,y) using yaw. You can try using accelerations from the IMU or velocities, if it gives you that, but that data is likely to be extremely noisy. Readings from multiple sensors are weighted, so if there's a disagreement, the noise will be incorporated into the estimate but hopefully you've set your covariances right and it won't affect the estimate too much.

4. I'd say there's no right or wrong, it depends on what data you are dealing with. Your encoders are your only source of data so whether you're calculating position or velocity, those values will depend on the accuracy of the encoders. It's just that you might want to integrate velocities instead of absolute measurements for convenience reasons. It might be applicable in your case and you might want to use the differential parameter (see 2) - the two estimations of yaw may differ greatly over the long run but for an instantaneous update the difference might not be much.

5. This goes back to a question in your second bullet point of "Would it somehow understand to adjust the X, Y values based on the IMU yaw reading being the correct one?". You need to tell the filter that you trust the IMU's heading more, and you do that with covariance values. The covariance value for yaw from the IMU should be lower than the covariance value for yaw from odometry. So you're likely correct in saying that the filter is not actually using the IMU.

P.S. Can't make this a wiki post like on StackOverflow. Paging @tom-moore for a less hand-wavy answer.