Call propagateVelocityCommands() at the full simulation rate unconditionally

[meyerj]

This PR fixes a bug introduced in #61. It addresses the problem described by @cobot here:

Hi, sorry, I was not particularly clear. I try to explain better with videos. I use a finer simulation than that from kobuki_gazebo/playground.world:

    <physics type="ode">
      <max_step_size>0.001</max_step_size>
      <real_time_factor>1</real_time_factor>
      <real_time_update_rate>1000</real_time_update_rate>
     ...

With this configuration, this is the default simulated behavior when spinning, without setting update_rate:

https://drive.google.com/file/d/1d7GYWod4_EAuk7q3NrzC_c_6DZ1Ft8By/view?usp=sharing

But setting it to 20 Hz I get:

https://drive.google.com/file/d/1T2ffTqze-EGvEItMplCb6JW-fnwzSAO0/view?usp=sharing

Looks like the robot cannot achieve the commanded velocity (6.6 rad/sec).

With the default simulation settings, robot spin faster, but still slower than commanded:

https://drive.google.com/file/d/15-lDS23H3EVi5Wj22oN_OAw86UDA67Ia/view?usp=sharing

But linear speed is fine, so I suppose the reason is that we skip 49 out of 50 update steps (1000 / 20 = 50). For the odometry calculation this doesn't matter, as we use step_time as time delta, but the IMU is not scaled accordingly. Here I made a fast change implementing the change I propose: throttle only the tf and topics publishing, not the plugins updates. Can u give it a try (note that I set bigger real_time_update_rate to 1000)?

following the approach proposed here.

Assumption:

Joint::SetVelocity() must be called in each simulation update step, or otherwise Gazebo will either reset it to zero for the next time step, or simulated friction and other physical effects reduce the joint velocity until the next SetVelocity() command, because Gazebo assumes that no torque is applied.

[corot]

thanks