{"action":"opened","issue":{"url":"https://api.github.com/repos/cra-ros-pkg/robot_localization/issues/262","repository_url":"https://api.github.com/repos/cra-ros-pkg/robot_localization","labels_url":"https://api.github.com/repos/cra-ros-pkg/robot_localization/issues/262/labels{/name}","comments_url":"https://api.github.com/repos/cra-ros-pkg/robot_localization/issues/262/comments","events_url":"https://api.github.com/repos/cra-ros-pkg/robot_localization/issues/262/events","html_url":"https://github.com/cra-ros-pkg/robot_localization/issues/262","id":138036625,"number":262,"title":"Allow for the filter to operate on a fixed time-delay","user":{"login":"NikolausDemmel","id":479562,"avatar_url":"https://avatars.githubusercontent.com/u/479562?v=3","gravatar_id":"","url":"https://api.github.com/users/NikolausDemmel","html_url":"https://github.com/NikolausDemmel","followers_url":"https://api.github.com/users/NikolausDemmel/followers","following_url":"https://api.github.com/users/NikolausDemmel/following{/other_user}","gists_url":"https://api.github.com/users/NikolausDemmel/gists{/gist_id}","starred_url":"https://api.github.com/users/NikolausDemmel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/NikolausDemmel/subscriptions","organizations_url":"https://api.github.com/users/NikolausDemmel/orgs","repos_url":"https://api.github.com/users/NikolausDemmel/repos","events_url":"https://api.github.com/users/NikolausDemmel/events{/privacy}","received_events_url":"https://api.github.com/users/NikolausDemmel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-03-03T00:36:45Z","updated_at":"2016-03-03T00:36:45Z","closed_at":null,"body":"AFAICT r_l currently has no explicit way to deal with delayed measurements (at least not if the delay is larger than the period of the filter update rate). Older measurements are simply applied to the current filter state as if their timestamp would match. In some situations this can be problematic (see e.g. http://answers.ros.org/question/227980/robot_localization-behavior-when-fusing-delayed-odometry-messages/).\r\n\r\nOne way to deal with this would be operating the filter at a fixed delay set in the configuration. That would mean, that measurements in the queue that are newer than `now() - filter_delay` are kept in the queue to be processed at a later time. This gives more time for the delayed measurements to arrive and be placed in the correct position in the queue.\r\n\r\nOf course the downside would be that the pose estimate is available only at a delay, but depending on the application that might be ok, and you can tune the tradeoff between filter delay and accuracy. You could even run multiple instances of the filter, one delayed, but more accurate, and one undelayed, but less accurate.\r\n\r\nThere are other ways to handle measurement delays, but this is one that should be quick to implement, and incur little computational overhead (except for maybe maintaining a larger priority queue of measurements).\r\n\r\n(P.S.: I hope it is ok to post these enhancement proposals / feature requests here. I don't expect for them to be worked on any time soon or ever, but I would like to discuss the principle, and hopefully I can also contribute some myself, as time allows)."}}