You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using laser scan matcher combined with odometry using robot_localization. In general works ok, but sometimes it does pose jumps without showing any error. This is different from issue #20: I don't experience that errors anymore. But jumps are by definition erroneous, as visual odometry must be continuous. So I propose to add a couple of parameters, for example min_jump_dist and min_jump_angle and ignore any pose update bigger than those values. Or alternatively, set a very big covariance proportional to the jump.
They can default to 0, meaning disable the feature.
What do you think? Make sense the idea?
The text was updated successfully, but these errors were encountered:
Not sure. #79 fixes one major source of jumps in the current code, caused by incorrect predictions, which could have been the root cause of what this issue was addressing. But jumps might also be caused by other things related to the sensor data and actual scan match failure.
Hard to know without more data or feedback from the reporter.
I'm using laser scan matcher combined with odometry using robot_localization. In general works ok, but sometimes it does pose jumps without showing any error. This is different from issue #20: I don't experience that errors anymore. But jumps are by definition erroneous, as visual odometry must be continuous. So I propose to add a couple of parameters, for example min_jump_dist and min_jump_angle and ignore any pose update bigger than those values. Or alternatively, set a very big covariance proportional to the jump.
They can default to 0, meaning disable the feature.
What do you think? Make sense the idea?
The text was updated successfully, but these errors were encountered: