Fix use with "external" gzclient

[Deanna Hood]

Meshes of parts on the belt are too large (collisions are fine) if running gzclient outside of the ARIAC roslaunch invocation

[Deanna Hood]

https://bitbucket.org/osrf/ariac/pull-requests/60

[Deanna Hood]

another issue with external clients is that ur10 meshes are refered to by the location on the machine running the gzserver. If the gzclient machine doesn't install them in that location it can crash with something like:

dhood@osrf-esteve:~/ariac_ws/ariac-docker/ariac-server [ariac-server (master *>)]$ GAZEBO_MASTER_URI=http://172.17.0.2:11345 gzclient
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::status: Permission denied: "/root/ariac_ws/install/share/osrf_gear/vendor/ur_description/meshes/ur10/visual/base.dae"
Aborted (core dumped)

That's particularly harsh because it's looking for meshes in /root. Otherwise you get:

GAZEBO_MASTER_URI=http://172.18.0.22:11345 gzclient --verbose

[Err] [Visual.cc:2763] No mesh specified
[Err] [SystemPaths.cc:410] File or path does not exist["/opt/ros/kinetic/share/osrf_gear/vendor/ur_description/meshes/ur10/visual/upperarm.dae"]
[Err] [Visual.cc:2403] No mesh found, setting mesh to a unit box

[Deanna Hood]

model visuals being displaying at unusual scale when using an external gz client resolved in https://bitbucket.org/osrf/ariac/pull-requests/60

the issue with mesh location can be resolved by sed but only if the logging is done as text not compressed. Once https://bitbucket.org/osrf/gazebo/issues/2136/gz-log-echo-renders-state-log-unplayable is resolved we can use gz log --echo to swap between compression formats