Revision history [back]

How large is that distance over which the RTK was not reporting? It seems like it's pretty far.

In general, as @johnconn said, the use of an IMU as an odometry source is not something I recommend. You appear to have a very nice IMU, as I'd have expected far worse performance over that kind of distance with just double-integration of IMU data. If I had to guess, there's some kind of bias in your accelerometer that is causing a slow lateral drift. You can try providing an image of the output (over that same distance, and preferably from the same location) when you just use the IMU and heading data. I'm assuming all of this came from a bag.

In any case, my recommendation would be to have some kind of odometry source, either from wheel encoders or through visual odometry. If the GPS quality is high and outages are not frequent, I think you can get away with a pretty noisy odometry source.

How large is that distance over which the RTK was not reporting? It seems like it's pretty far.

In general, as @johnconn said, the use of an IMU as an odometry source is not something I recommend. You appear to have a very nice IMU, as I'd have expected far worse performance over that kind of distance with just double-integration of IMU data. If I had to guess, there's some kind of bias in your accelerometer that is causing a slow lateral drift. You can try providing an image of the output (over that same distance, and preferably from the same location) when you just use the IMU and heading data. I'm assuming all of this came from a bag.

In any case, my recommendation would be to have some kind of odometry source, either from wheel encoders or through visual odometry. If the GPS quality is high and outages are not frequent, I think you can get away with a pretty noisy odometry source.

How large is that distance over which the RTK was not reporting? It seems like it's pretty far.

In general, as @johnconn said, the use of an IMU as an odometry source is not something I recommend. You appear to have a very nice IMU, as I'd have expected far worse performance over that kind of distance with just double-integration of IMU data. If I had to guess, there's some kind of bias in your accelerometer that is causing a slow lateral drift. You can try providing an image of the output (over that same distance, and preferably from the same location) when you just use the IMU and heading data. I'm assuming all of this came from a bag.

In any case, my recommendation would be to have some kind of odometry source, either from wheel encoders or through visual odometry. If the GPS quality is high and outages are not frequent, I think you can get away with a pretty noisy odometry source.

EDIT: Off the top of my head, and looking at your original drift image, if I had to guess, what you're seeing is this:

1. Let's ignore the IMU for a moment. Robot starts moving forward, receiving RTK inputs. At every RTK message, the filter is updated with a new pose. However, when it receives that new pose, the magic of matrix inversion means that if you don't have a velocity reference, the filter will actually produce a non-zero velocity, depending on the delta in your last two measurements.measurements. As long as you are receiving RTK inputs, this auto-generate velocity doesn't matter, because you are constant updating the pose.
2. You then cease to receive RTK measurements. The last velocity value that the filter produced, however, small, persists, because you have no velocity reference to correct it.
3. Now throw in the IMU. It won't help you, because it's just integrating linear acceleration data. So even if it reads that the vehicle is not accelerating laterally, it won't matter, because you already have a non-zero lateral (Y) velocity.

You need a velocity reference. If I were you, I'd take advantage of your vehicle's kinematics, and feed in a fake Y velocity measurement of 0 all the time to the filter. That is, unless you have to worry about things like sliding laterally in the mud.

How large is that distance over which the RTK was not reporting? It seems like it's pretty far.

In general, as @johnconn said, the use of an IMU as an odometry source is not something I recommend. You appear to have a very nice IMU, as I'd have expected far worse performance over that kind of distance with just double-integration of IMU data. If I had to guess, there's some kind of bias in your accelerometer that is causing a slow lateral drift. You can try providing an image of the output (over that same distance, and preferably from the same location) when you just use the IMU and heading data. I'm assuming all of this came from a bag.

In any case, my recommendation would be to have some kind of odometry source, either from wheel encoders or through visual odometry. If the GPS quality is high and outages are not frequent, I think you can get away with a pretty noisy odometry source.

EDIT: Off the top of my head, and looking at your original drift image, if I had to guess, what you're seeing is this:

1. Let's ignore the IMU for a moment. Robot starts moving forward, receiving RTK inputs. At every RTK message, the filter is updated with a new pose. However, when it receives that new pose, the magic of matrix inversion means that if you don't have a velocity reference, the filter will actually produce a non-zero velocity, depending on the delta in your last two measurements. As long as you are receiving RTK inputs, this auto-generate auto-generated velocity doesn't matter, because you are constant updating the pose.
2. You then cease to receive RTK measurements. The last velocity value that the filter produced, however, small, persists, because you have no velocity reference to correct it.
3. Now throw in the IMU. It won't help you, because it's just integrating linear acceleration data. So even if it reads that the vehicle is not accelerating laterally, it won't matter, because you already have a non-zero lateral (Y) velocity.

You need a velocity reference. If I were you, I'd take advantage of your vehicle's kinematics, and feed in a fake Y velocity measurement of 0 all the time to the filter. That is, unless you have to worry about things like sliding laterally in the mud.