make shadowhand_motor.srdf more generic

[ugocupcic]

(from sr_hand_kinematics)

[guihomework]

Wouhou, did it for the srdf, using xacro. Can theoretically handle any hand (any number of finger/is_lite) + prefix in joint_names but the problem is now on yaml files. They also would need the prefix argument to be passed as well as "if" in case some fingers are not there etc...
Do you have a preference/ideas to generate the yaml ? otherwise one idea would be to create one yaml per finger and include or not in the launch file (but I think for loading on parameter server it must be in single file, maybe concatenating the files with a system call like "cat" ?)
suggestions welcome.

[ugocupcic]

what about having a python script utility which parses a default yaml file and pushes the properly aggregated parameters to the parameter server? It should be easier to maintain and more flexible.

[guihomework]

I am not sure I understand your idea : Now the xacro for SRDF works like this and can be called from a lunch file
rospack find xacro/xacro.py shadowhands.xacro.srdf ff:=1 th:=1 mf:=1 rf:=1 lf:=1 is_lite:=0 >
but we need an equivalent generator for yaml files.
I don't see the point on reading something from parameter server right now

[toliver]

Are you talking about the yaml files to define the controllers?

[guihomework]

No moveit files

• kinematics.yaml
• fake_controller.yaml
• joint_limits.yaml
• ompl_planning

[toliver]

I think Ugo's proposal makes sense. The default launchfiles created by MoveIt simply load these yaml files to the parameter server (e.g. in planning_context.launch).

They could be modified to call instead a python script that reads the default yaml file, adds prefixes/removes undesired joints/fingers, and then loads the result to the parameter server.

[guihomework]

So instead of generating the correct yaml, you want to use the full yaml, parse it, and load correct parameters on the server. I thought it would be cleaner to read a template file (that could also be yaml i you dont' like the yaml embeded in xml (see email)), except with nice valid yaml language that the python parser could find in the template instead of finding what exists and should not be there. The only advantage I see, is that you don't have to invent a new macro language. However a new macro language for yaml could be more widely used later on...

I guess this solution could work nice for the yaml but a similar technique might be difficult to use for the srdf or did you plan to do this the same way ? using the full srdf, parsing and cleaning what is unnecessary and prefixing everything (prefixing is at various places, non only joints), and collision pairs are quite complex to handle too. I am double checking the generated collisions (500 pairs to check) and this srdf generator should be ok fully ready.