Store the set of joints involved in a received trajectories and
use this set to constrain serialization of solutions for execution to those joints only.
If this is not done, all joints of the RobotModel are considered for the trajectory,
but we might not have controllers defined for all joints, so execution will fail.
Maybe, a better approach might be to just ask the MTC planner to execute a specific solution id.
However, this requires that the planner node is still available.
As INCLUDE_DIRECTORIES of target_link_libraries always go AFTER those from target_include_directories,
we need to explicitly provide the include order for local targets.
I very much considered just removing the protected inheritance again,
but it would add unnecessary code duplication.
Take note, the overriding `insert` function bypasses the Wrapper and directly forwards to the wrapped container.
This is somewhat dirty and could be an issue for anyone inheriting from `Task`.
`add` falls back to `insert` for both structures,
but `add` throws exceptions and does not provide a return value.
`insert` provides standard STL container access.
So far, returning false from the processor function, just skipped further traversing the current child (depth-wise).
Now, traversal is completely aborted, even not traversing the remaining siblings of the current child.
Having a single boolean return value, we cannot distinguish both cases.
We need the new behaviour for 8061945c15bea22e8f8899c987bc28e3542885aa.
Previous code was generating the error on changing object_name in config/panda_config.yaml file because of this bug as here we are overwriting the object_name as "object" which brought the inconsistency in code.
Having multiple solutions, automatic publishing of intermediate solutions is confusing.
One never knows, which one is the final one. If desired, the user should setup a hook for this.
Using a joint-space interpolator to move back to start pose,
we avoid pose drift in the Cartesian loop, which pushes the robot
into its joint limits over time. Fixes#113.