Load HERB model from parameter server in non-sim

[ClintLiddick]

To support multiple arm/hand configurations, load the HERB urdf/srdf from /robot_description and /semantic_robot_description. Additionally, need to test the end effectors to determine if they are BarrettHands or dummy EEs.

Depends on personalrobotics/or_urdf#26 and personalrobotics/prpy#346

[mkoval]

I would prefer to not try to infer which hands are installed from properties of the Robot that we load from URDF, e.g. link and joint names. This does not work well for hands like the BH-280 and BH-282, which differ only by small parameter changes. Instead, I would rather a launch file to store which end-effectors are installed on the parameter server, e.g. in left_hand_type and right_hand_type string parameters.

Also, could you merge master into this? I likely introduced a conflict in #103 or #105. 😁

[mkoval]

Why is this necessary?

[ClintLiddick]

JSON requires escaped control characters,and rosparam returns with raw newlines (apparently) so I was getting parse errors. I could do the string replacement with the escaped newlines and returns, but spaces or nothing are fine for XML.

[cdellin]

@mkoval I could go either way on this, but one advantage of the derive-from-URDF approach is that it also works in simulation mode ... I'd imagine that it will be useful to have different HERB models lying around (with different hand types) that we'd want to use with HerbPy, and it would be annoying to have to start up a ROS master / parameter server and set parameters just to get the hands to work correctly.

(I'm not sure the best way to accomplish this though -- URDF does support custom XML elements, so maybe we could define a <left_hand_type> tag in the HERB URDF, and expose that to HerbPy somehow? Although I shudder thinking how one might accomplish that ...)

[mkoval]

I agree that it's important to be able to load different HERB configurations in simulation. However, I still don't think the correct way of doing so is to infer the configuration from the OpenRAVE model.

We can add the same arguments (e.g. left_hand_type, right_hand_type) toherbpy.initialize that default to HERB's nominal configuration (BH-282 right, BH-280 left). If we're running on the real robot, then we can ignore these function arguments and read the same values from the parameter server. Ideally, we would throw an error if the two values do not match.

This means that herbpy.initialize is responsible for choosing which URDF file to load for a given robot configuration. I prefer this for two reasons:

1. It's easier to go from more structured data (left_hand_type and right_hand_type) to less structured data (a file path) than the inverse.
2. This allows us to programmatically generate a HERB model, e.g. with xacro, if it becomes unwieldy to build all possible hardware combinations.

[cdellin]

Sounds good to me!

[ClintLiddick]

I'm going to try to incorporate the BH282 (whatever is necessary) and see what the herbpy.initialize argument approach looks like since it already does all the URDF work. There will definitely have to be some switching code inside HERBRobot itself though to bind to the correct subclass for TSRLibrary and whatnot.

[mkoval]

This is blocked on the refactoring HERB's TSRs.