The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 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.
| | 2 | No.2 Revision |
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.
| | 3 | No.3 Revision |
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?
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
