Gazebo causes jump backwards in time

[bsaund]

launching victor.launch, killing, then relaunching can cause realtime's joint_state_publisher to crash because launching gazebo can cause a jump backwards in time.

Traceback (most recent call last):
  File "/home/armlab/catkin_ws/src/kuka_iiwa_interface/victor_hardware_interface/scripts/joint_state_publisher.py", line 178, in <module>
    pub.run(rate)
  File "/home/armlab/catkin_ws/src/kuka_iiwa_interface/victor_hardware_interface/scripts/joint_state_publisher.py", line 114, in run
    rate.sleep()
  File "/opt/ros/noetic/lib/python3/dist-packages/rospy/timer.py", line 103, in sleep
    sleep(self._remaining(curr_time))
  File "/opt/ros/noetic/lib/python3/dist-packages/rospy/timer.py", line 163, in sleep
    raise rospy.exceptions.ROSTimeMovedBackwardsException(time_jump)
rospy.exceptions.ROSTimeMovedBackwardsException: ROS time moved backwards
[victor/joint_state_publisher-1] process has died [pid 59304, exit code 1, cmd /home/armlab/catkin_ws/src/kuka_iiwa_interface/victor_hardware_interface/scripts/joint_state_publisher.py __name:=joint_state_publisher __log:=/home/armlab/.ros/log/bc0ab0b6-4b5d-11eb-a4fe-3500f8258116/victor-joint_state_publisher-1.log].
log file: /home/armlab/.ros/log/bc0ab0b6-4b5d-11eb-a4fe-3500f8258116/victor-joint_state_publisher-1*.log

Related to #7

[PeterMitrano]

my first hunch here would be that use_sim_time is set to True when gazebo get's launch, which is bad and we don't want (assuming you're using the real robot)