Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Your question is a bit implied, but what you noticed (your robot not stopping after the last command input has been given) is typically addressed by adding a time-out mechanism to your driver.

Keep track of when the last Twist was received and if dt becomes too large, automatically stop.

That way even missed 'stop' commands won't lead to your robot continuing on forever, as it will have timed out long before.

Note that adding such a time-out mechanism to your base driver (ie: the code running on your Arduino) will require your Twist producer to keep publishing new messages, at a rate at least as high as the inverse of the time-out you've configured your driver to use.

Your question is a bit implied, but what you noticed (your robot not stopping after the last command input has been given) is typically addressed by adding a time-out mechanism to your driver.

Keep track of when the last Twist was received and if dt becomes too large, automatically stop.

That way even missed 'stop' commands won't lead to your robot continuing on forever, as it will have timed out long before.

Note that adding such a time-out mechanism to your base driver (ie: the code running on your Arduino) will require your Twist producer to keep publishing new messages, messages at a rate at least as high as the inverse of the time-out you've configured your driver to use.

Your question is a bit implied, but what you noticed (your robot not stopping after the last command input has been given) is typically addressed by adding a time-out mechanism to your driver.

Keep track of when the last Twist was received and if dt becomes too large, automatically stop.

That way even missed 'stop' commands won't lead to your robot continuing on forever, as it will have timed out long before.

Note that adding such a time-out mechanism to your base driver (ie: the code running on your Arduino) will require your Twist producer to keep publishing new messages at a rate at least as high as the inverse of the time-out you've configured your driver to use.


Edit: thanks for the code, but I don't see any timeout -- or at least, not implemented in a way I would expect given your initial question.

I'm also rather uncertain as to what your question now is: what is it that you feel is not working now / not appropriate to do? I only see a single Subscriber (good). Are you saying there is a 0.5 second delay between publishing a Twist and receiving it in your callback?