Disable cmd_vel_timeout

[mwlock]

Hey !

Is there any way to disable the cmd_vel_timeout for the diff drive controller? It is not very apparent how to do this in the documentation. I have also checked the source code as well and it does not seem possible in its current implementation.

I am happy to create a PR if needed.

See this https://github.com/cyberbotics/webots_ros2/issues/468 for more context.

[DrAndyWest]

I just want to echo the need for this enhancement. Had awful trouble with Clearpath Jackal hardware, where the twist_mux uses it's own timeout, and does not repeat joy commands if they don't change.

Therefore, the robot would suddenly stop even when commanding full velocity if the joystick input wasn't changing. Work around was to add a large timeout for the diff drive controller.

A 0.0 = ignore option like most ROS nodes would be perfect.

[gavanderhoorn]

and does not repeat joy commands if they don't change.

isn't that a joy (as in: the node) or even an OS-level setting? Afaik, twist_mux doesn't even interpret the incoming msgs. It just forwards them.

---

Edit: should be auto_repeat in the joy_node. If that's set to 0, it won't republish at a fixed rate. Also in the readme:

~autorepeat_rate (double, default: 0.0 (disabled))

• Rate in Hz at which a joystick that has a non-changing state will resend the previously sent message.

not claiming being able to disable the command timeout would not be a good addition of course.

[DrAndyWest]

I found the behaviour also happened for simple command-line publishing at a set rate (avoiding the autorepeat in the joy node), into twist_mux. I am using an autorepeat_rate of 20 Hz, therefore, the default.

Twist Mux does look to check if there has been a change in values, but I am not sure this actually gets used - your link to the callback being evidence it is not.

Either way, I do feel a bit uncomfortable with the controller being able to issue zero velocity commands when the command input is non-zero, from a transparency point of view.

[gavanderhoorn]

Twist Mux does look to check if there has been a change in values, but I am not sure this actually gets used - your link to the callback being evidence it is not.

looks like that's dead code indeed.

Either way, I do feel a bit uncomfortable with the controller being able to issue zero velocity commands when the command input is non-zero, from a transparency point of view.

it's pretty important functionality actually. Many a run-away robot has been saved when it lost connection to its controller for whatever reason and was driving max-velocity into a wall, or water, or something else. Standard functionality as well for velocity-control interfaces/controllers.

But again: not claiming it can't be better documented or should be something that can be disabled.