Support saving to macro/xacro file structure

[akgoins]

Instead of only being able to save to a URDF, we could add a right click option to the link/joint tree on the left to "insert xacro break point". This would create two visible horizontal rules that could be shifted up/down in order to define what gets saved to a macro.xacro file. To distinguish between multiple macro.xacro files (e.g. robot vs. EE), each set of horizontal rules could be colored differently or have a different width. The user would have the option to export as a single URDF, or as multiple macro.xacro files with one top level .xacro file. Upon export, there would be several prompts to give file names for each macro file or have a way to edit properties for each subsection in the tree. This would also have to have a right click option to be able to delete the break points if they are no longer desired.

[gavanderhoorn]

@akgoins: can you elaborate a bit more on how you'd like those break points to work? URDFs encode a tree structure, so break points would necessarily have to be inserted at specific places in branches, correct?

Do you have any ideas about how to deal with macro arguments? Would users be free in specifying whatever arguments they want? If not: are we going to restrict them?

And what kind of UI would you like to see: allow arbitrary expressions in the property browser widget, or should there be some export wizard where certain values can be replaced with xacro properties?

[akgoins]

@gavanderhoorn, Yes, the break points would be inserted into the "chain" tree where the joint structure is shown. This would allow the user to place the break at the desired location(s) in the tree, separating end-effector from robot, or robot arm from mobile platform, etc. I was originally thinking that we might keep the tree structure intact, but I am now thinking that it might be easiest to separate the chain into two separate RobotModel objects (more discussion about this later).

Initially, I would think that the first commit might not support macro arguments. In order to support them, there would have to be a separate window for macro options that would allow the user to insert and define arguments and values. We have two ways of supporting this:

1. Every property of each item (link or joint) in the list would have to be able to support taking in an argument name instead of a value. For example, the joint offset could be specified by a fixed value, or it could take in the argument ${arg x_offset} which would have to be passed in by the file above it or given a default value.
2. We could add an extra option at the bottom for using arguments to override specific fields. For example, if joint1 were selected, there would be another "macro" subfield that would allow the user to add an argument. The user would select the field to override (axis:x) and an argument to use (x_offset). This method would make it easier for the user in that we could provide a combo box drop down menu listing all of the arguments available and prevent typos that might occur in option 1. This would also remove the need to change all of the combo boxes to text boxes to allow the entry of text instead of numbers.

As for UI, I was thinking that in the top window, instead of having the RobotModel be the top level, we could add at the same level a Xacro option which can include all of the arguments and values which will be passed into the lower level macro files which get called. Each macro file could be its own separate list in the window so that the view now looks like:

Xacro
RobotModelBase
RobotModelEE

where each item can be selected, expanded, and options edited. This would make the delineation between files the clearest.

[git-jkb]

As a group, we primarily work from xacros in our organization. This would be quite helpful to be able to output xacros from this utility.

Tool is fantastic so far and this would be a really helpful addition,
-Josh Kalin