-
Notifications
You must be signed in to change notification settings - Fork 525
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
Add service to reset odometry #564
base: melodic-devel
Are you sure you want to change the base?
Add service to reset odometry #564
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable, but I don't think we can accept it into ros1 since it will break ABI. I'm not sure how much of an issue ABI compatibility is when using pluginlib though... @bmagyar @ipa-mdl thoughts?
#include <tf/tfMessage.h> | ||
#include <std_srvs/Trigger.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Please alphabetize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
a9d5c21
to
1231672
Compare
I have two points:
Additionally: services are generally not preferred for any deployment where you want to record/monitor the behaviour of the system. |
friendly ping, would be nice having this feature on melodic |
@alcantara09 @caioaamaral |
Hi @bmagyar, |
I want to know if this "reset odom" method is feasible. How should I use it to solve the problem? Can it be used on the Husky robot with Melodic? |
Why:
The odometry state relies on the assumption that the node that implements the controller_manager interface has the same life cycle as it. In other words is assumes that the internal state is zero and any incoming messages are due robot movement. However this is not true when restarting the nodes but not the actual physical system. In this case the first reading of encoder position will be the current encoder position of the controller, what will be interpreted as being a valid input and will generate a spike in velocity, moving the internal state to a position far way from the origin.
How:
This PR exposes a service to reset the odometry state of the diff_drive_controller. This allow us to reset the odometry in cases when you have to restart your system, but the actual controller is not resetted.
To overcome the initialization issue, the first reading of the controller will also be considered as an offset. This also ensures that no jump will occur when resetting the odometry state.