Add planner name to trajectory info

[sjahr]

Add planner id to SubTrajectory SolutionInfo.

[codecov]

Codecov Report

Merging #5 (b16b438) into ros2 (5ea2140) will increase coverage by 0.12%.
The diff coverage is 81.67%.

@@            Coverage Diff             @@
##             ros2       #5      +/-   ##
==========================================
+ Coverage   41.53%   41.64%   +0.12%     
==========================================
  Files          81       83       +2     
  Lines        7933     7962      +29     
==========================================
+ Hits         3294     3315      +21     
- Misses       4639     4647       +8     

Files Changed	Coverage Δ
...moveit/task_constructor/solvers/pipeline_planner.h	0.00% <ø> (ø)
...oveit/task_constructor/solvers/planner_interface.h	100.00% <ø> (ø)
core/src/solvers/pipeline_planner.cpp	0.00% <0.00%> (ø)
core/src/storage.cpp	50.32% <0.00%> (-0.32%)	⬇️
...tion/motion_planning_tasks/src/task_list_model.cpp	22.83% <0.00%> (ø)
core/src/stages/move_relative.cpp	51.62% <50.00%> (-0.01%)	⬇️
core/include/moveit/task_constructor/storage.h	85.11% <91.67%> (-0.76%)	⬇️
core/src/stages/connect.cpp	87.50% <94.29%> (+1.37%)	⬆️
...e/moveit/task_constructor/solvers/cartesian_path.h	100.00% <100.00%> (ø)
...eit/task_constructor/solvers/joint_interpolation.h	100.00% <100.00%> (ø)
... and 1 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[v4hn]

Why not optionally set (or add to) the comment instead of creating a new field?
Also, the pipeline planner already has a property "planner" which is basically what you implement via getPlannerId.
I would propose to implement this one in the other planners as well and use the property from there instead of implementing it again.

I did not review the rest of this patch.

[sjahr]

Thanks for your review!

Why not optionally set (or add to) the comment instead of creating a new field?

I think it is nicer to have a specifically named field rather than an arbitrary "comment" field for this data

Also, the pipeline planner already has a property "planner" which is basically what you implement via getPlannerId.

The refactored version of the PipelinePlanner we're using here does not. See PR against main mtc repository for details

[sea-bass]

Thanks for doing this!

My comment was less about the struct vs. pair data structure, and the fact that if you ever had to add more data to this it would be challenging. Same still holds here because the struct has Pair in its name. Is there some more generic name we can use like TrajectoryInfo?

... and same with the variable names that use this data type, which are still called vector and pair

[sjahr]

I think we should keep it like this for now because the name describes what it is and if we add more to this data structure in the future the name can be updated accordingly. Despite the fact that this could also be of datatype pair, I think making it a struct made the code more readable 👍

[sjahr]

TrajectoryInfo is very generic and MTC has already a datatype called like this.

[sea-bass]

Sounds good -- I can't think of anything better anyhow.

[sea-bass]

LGTM!

[rhaschke]

@sjahr: I'm going through all commits PickNik committed to the ros2 branch. For this one, could you please argue why this additional field is actually needed? How do you handle generators, which also generate trajectories but do not have a planner necessarily?

[sjahr]

I think it is useful to include information about the planner that created a solution into the solution info. We're using it e.g. for debugging and introspection. I did not think about the generator use-case, but I think in that case the field could be left empty or populated with something like "generated" (depending on how it was actually created). Before the parallel planning API, I guess it was possible to infer the planner that was used from the pipeline id but now, the pipeline planner uses multiple algorithms and without this field it would be harder to say which one actually created the best solution. Just out of curiosity: Are there any trajectory generator stage examples in the mtc main repository?