Revision history [back]

This isn't a proper answer sorry but it's too long an explanation for comments and it may give you some leads to look into.

I would make sure ethzasl sensor fusion works on Indigo because from the wiki page it looks like Groovy is the latest distribution that's supported, so there may be compatibility issues (hopefully someone more familiar with ROS than me can tell you).
I don't have any personal experience with ethzasl (I'm using the robot_localization package). But what I can say is that I see similar behavior quite a bit, and it's usually because sensor data is being converted to odometry in a reference frame, and somewhere along the way an angular offset is added to the data.

For example if you line up your robot with the 'X' axis of your global frame and drive it in a straight line but your odometry in that frame shows the robot travelling at an angle to the 'X' axis. E.g:

My global, local and GPS frames line up with the 'X' and 'Y' axis, but my global and GPS data is reported at an angle.

Is this similar to what you're seeing? I suggest you try something similar, drive your robot in a straight line outside and plot the odometry in each frame in Excel.

If this looks familar it's usually because your IMU heading has been distorted (nearby metal objects will do that) or because yaw-related parameter has been set incorrectly. Is one of your sensors a GPS? If so then it will almost certainly be doing some sort of geodetic conversion to produce an absolute pose - and for such conversions it's critical that parameters such as your magnetic declination and yaw offset are correct (as per REP-103 and REP-105, most IMU's read 0 when pointing North, whereas ROS expects them to read 0 pointing East). If you're using a provided launch file your robot may not report sensor data in the way the launch file expects it to.

I'm sorry I can't give you more specific advice, but hopefully this will give you some things to check. And in general, the more information you can provide about the problem the easier it is for others to debug - if you could post some bag files or graphs of your odometry similar to the one above that would help.

This isn't a proper answer sorry but it's too long an explanation for comments and it may give you some leads to look into.

I would make sure ethzasl sensor fusion works on Indigo because from the wiki page it looks like Groovy is the latest distribution that's supported, so there may be compatibility issues (hopefully someone more familiar with ROS than me can tell you).
I don't have any personal experience with ethzasl (I'm using the robot_localization package). But what I can say is that I see similar behavior quite a bit, and it's usually because sensor data is being converted to odometry in a reference frame, and somewhere along the way an angular offset is added to the data.

For example if you line up your robot with the 'X' axis of your global frame and drive it in a straight line but your odometry in that frame shows the robot travelling at an angle to the 'X' axis. E.g:

My global, local and GPS frames line up with the 'X' and 'Y' axis, but my global (red) and GPS (green) data is reported at an angle.

Is this similar to what you're seeing? I suggest you try something similar, drive your robot in a straight line outside and plot the odometry in each frame in Excel.

If this looks familar it's usually because your IMU heading has been distorted (nearby metal objects will do that) or because yaw-related parameter has been set incorrectly. Is one of your sensors a GPS? If so then it will almost certainly be doing some sort of geodetic conversion to produce an absolute pose - and for such conversions it's critical that parameters such as your magnetic declination and yaw offset are correct (as per REP-103 and REP-105, most IMU's read 0 when pointing North, whereas ROS expects them to read 0 pointing East). If you're using a provided launch file your robot may not report sensor data in the way the launch file expects it to.