Profiles for ProcessPlanningServer should have option for program local profiles

[johnwason]

Currently the profiles for use with ProcessPlanningServer are global for the server, so that if programs have their own profiles they need to be added and deleted from the server if they are not reused between programs. It would be better to have the profile dictionary be supplied with the program request so there isn't any crosstalk between programs.

[Levi-Armstrong]

The goal for the planning server was to have all profiles defined in an xml file or series of xml files which can be loaded at runtime by the planning server so they can be dynamically loaded. It may make fore sense to use yaml or json for the profiles which would be good to discussion on what format we want to use for them. Also I agree with you that it would be good to enable the ability to provide the profiles through the planning request. The two things we need to decide on is the format that will be sued for profiles and I need to implement plugin support because some will require the ability to specify plugins to be loaded like in the case of descartes edge evaluator and vertex evaluator. Do you have an good examples for doing this agnostic of ROS? I have been looking at how Ignition Robotics does this using class loader, but would be interested to hear what you recommend.

[johnwason]

For the teach pendant, each instruction will have its own parameters. The best example I can think of is the Staibli Val 3 MDESC structure they pass as part of move commands. https://usermanual.wiki/Document/val3referencemanual.275627616 . The profile will probably be passed using the API, so there won't need to be any parsing. Could we add a ProfileDictionary entry to Instruction, so that each instruction can override the main profiles?

[Levi-Armstrong]

Are you requesting to update the Instruction class to have the profile key? Right now move and plan instruction have a profile key.

[johnwason]

Maybe it would make sense to have a ProfileDictionary included in PlanningRequest so each individual request can have its own set of profiles. Right now, if a program needs a different set of profiles they would need to be registered with the main planning server, but if all the requests have different profiles this will cause potential name collisions or memory leaks if they aren't unregistered.

[Levi-Armstrong]

I am on board with that. What if we add a getCombined where it merges two dictionaries and the ones in the request take precedents. Like how we are handling ManipulatorInfo.

[Levi-Armstrong]

Or we can namespace the dictionary where in the command language you would use namespace::profile.

[Levi-Armstrong]

Still allowing profiles to be added in the request they would just get put in a namespace provided in the request.

[johnwason]

Yeah, I like the getCombined idea. We can use the namespace::profile as a convention for the keys. I am not sure it would need special logic to implement.

[mpowelson]

@Levi-Armstrong Would it be so bad to add an optional profile override to the instruction? My usecase is wanting to specify time parameterization scaling factors in the instruction, but I could also imagine things like wanting to disable collision checking for a single instruction that is otherwise the same as everything else. It could be a map where the task name is the key. Then we add looking for overrides to the utilities that look up profiles. This keeps someone who has a trajectory where everything is the same except for one task from having to essentially make a profile for each instruction and pass them along and setting up profile remappings for every task except the one that changes