Publishing alternate robot models to Rviz

Now using the MissionCtrl.launch file, we can publish multiple Valkyrie's at once to Rviz and control their pose independently.  Also, we can adjust the opacity of each model, allowing one to be a "ghost".  Here are some potential uses:

1. Display both actual (Gazebo) Valkyrie pose as a ghost and the state-estimated Valkyrie pose in order to tune state estimator and train the operator to expect when or how the estimated pose may differ from the actual pose in order to give conservative commands or ask for update state and sensor information
2. "Loop play" forward kinematic plans in Rviz.  The operator should be able to send a high-level command and current state information to the Mission Control planner in order to preview and approve the planner's result prior to sending the same high-level command across the UDP or TCP connection to the Valkyrie_System_Manager in the Gazebo Plugin.  One way of previewing the plan would be to use a ghost of Valkyrie in Rviz that plays a loop of the planned trajectory for the links going forward in time.  Possible additional functionalities would be to pause the plan and drag a slider to show different future frames in time and to slow down playback for closer inspection.  Note that this is only a kinematic preview.
3. "Loop play" forward dynamics in Rviz. This functionality would take a planned trajectory and simulate the forward dynamics as well as the controller response.  This could then be viewed in Rviz as a ghost, similar to the way that kinematic plans could be viewed. Donghyun calls this the "Dynamically Consistent Media Player." If the actual Gazebo simulation environment is too noisy, this may not be of any use because we are using torque control on the actual robot and the dynamics in the actual gazebo simulation may diverge relatively quickly from our internally simulated dynamics within Mission Control.

Alternate RobotModel's are published to Rviz by remapping to alternate robot_description's within the <node> tags in the launch file for both the joint_state_publisher and the robot_state_publisher and adding a tf_prefix to one of the robot_state_publisher's tf's.  Here is an excerpted example from the launch file:

First you have to load a URDF and an alternate tf_prefix onto the ROS parameter server:

<param name="robot_description_2"    textfile="$(find r5_src_simulation)/urdf_model/r5_urdf.urdf" />
<param name="tf_prefix_2" value="ghost" />

Then you can remap parameter names for the second joint_state_publisher and robot_state_publisher so that these do not conflict with or overload the URDF and tf_prefix used for the first robot.

<node name="joint_state_publisher_2" pkg="joint_state_publisher" type="joint_state_publisher" >
    <remap from="robot_description" to="robot_description_2" />
    <remap from="joint_states" to="joint_states_2" />
</node>
<node name="robot_state_publisher_2" pkg="robot_state_publisher" type="state_publisher">
    <remap from="robot_description" to="robot_description_2" />
    <remap from="joint_states" to="joint_states_2" /> 
    <remap from="tf_prefix" to="tf_prefix_2" />
</node>

Actually, if you are using the same URDF for both models, then you actually do not need a separate robot_description for each publisher.  But, you do need separate joint_states and tf_prefix's.

Here are some fun screenshots of the results: