The behaviour you describe ("velocities are set to zero after certain time out") is very controller specific. It's not a general property of velocity controllers (or even velocity controllers in ros_control).
It is a typical property of so called "mobile base controllers" (or drivers) though, as it makes a lot of sense for those controllers to do that: imagine a tele-opped robot going out of range of its controller, without a time-out on the (last) velocity command, the robot would continue executing whatever was the last command without any way for the operator to stop it.
The time-out automatically resets target velocity to zero after a short time-out, resulting in a stopped robot. If new commands come in, the time-out is reset and things keep working as normal (ie: the robot does not stop). If the operator purposefully commands a zero velocity (because he wants to stop the robot), things also work as expected: a zero-command also resets the time-out, and as the target is zero velocity, the robot stops.
But in the case of "joint_group_velocity_controller" which refers to "forward_joint_group_command_controller " , I am unable to find where the velocities are set to zero after a specified time ?
That is because the behaviour I described earlier just hasn't been implemented in those controllers.
Could it make sense for these controllers to have a time-out? Probably. But it would be good to ask the original developers why there currently isn't one, just to make sure we're not missing some rationale for why they shouldn't have it.
Is it going to get added: that will depend on someone contributing it.
