bmagyar
commented
3 years ago I have two points:
- The variable name
first_datais unclear when you first read it. Using something more specific, such asodometry_resetwould be desirable. - Using a service in a controller is not fortunate as it is a blocking call unless explicitly handled on a separate thread. I suggest introducing a topic for this with a realtime subscriber and triggering the reset in the next update loop after receiving the reset request. That way you can also eliminate the subject of the first point as you won't need a flag to convey this change ;)
Additionally: services are generally not preferred for any deployment where you want to record/monitor the behaviour of the system.
caioaamaral
alcantara09
nblkStudy
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.