-
Notifications
You must be signed in to change notification settings - Fork 902
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix to avoid dt = 0 #804
base: ros2
Are you sure you want to change the base?
Fix to avoid dt = 0 #804
Conversation
This suggests you have an issue with your sensor data. Why would one sensor produce two measurements with identical timestamps and different values? |
I think you're right about sensor data having problems. However, there is a possibility that dt=0, so I don't think the equal sign should be included in the judgment condition, what do you think? |
I am trying to determine a valid use case for dt = 0. Those time deltas are calculated per sensor, so if you get dt = 0, then your sensor data is wrong. There's a delicate balance to be had between making the filter robust and masking bad data. |
The correct sequence is if curTimestamp > lastTimestamp. |
Trying to figure out why the IMU differential tests are failing. I'll have to look further into that when I have time. |
Sorry, looking at this once more, and what I said originally is still true: if you have to identical time stamps coming in for the same sensor, then your sensor is producing faulty data. However, I agree that the filter can recognize the error and yell at the user instead of using the measurement, especially if differential mode is true. |
Can we do something like this?
|
If differential == true and last_massage_times == msg.header.stamp, calculated dt is equal to zero. So, velocity is to be Nan and robot_localization 's output is Nan.
I think that it is necessary to modify the judgment condition so that dt = 0 does not occur.