Probably the most invasive format patch, also changing some internal API.
I deliberately disabled ClassCase and MethodCase checks for the moment
to avoid public API changes in this patch set.
The PROPAGATE concept BOTH declared the stages *will* propagate solutions in
either direction. ANY, on the other hand, only means the propagation
direction is *not resolved yet* (but will be at planning time).
BOTH was originally described to support a more general control flow
than was eventually decided to support. The four exclusive Stage interfaces
CONNECT, PROPAGATE_FORWARDS, PROPAGATE_BACKWARDS, and GENERATOR
do not allow for BOTH as a valid setup anymore, unless you setup a very
convolved task like `Alternatives(GEN, PROP) - Alternatives(PROP, GEN)`
which would be very complex to inspect. The same functionality can still
be achieved more readable as `Alternatives(Seq(GEN, PROP), Seq(PROP, GEN))`.
The confusion between BOTH (propagator *will* send in both directions) and
ANY (propagator will send in *either* direction, decided during init) led
to a lot of confusion with users and was not fully accounted
throughout the pipeline.
Adjust tests.
Notice the difference between ANY (unresolved propagator) and UNKNOWN
(a container before introspecting its children). propagators still
report UNKNOWN as requiredInterface though to simplify control flow.
The simplification enables a much simpler linear inference of the connective
structure of a task, as the first interface direction is always given.
Additionally, unify the resource setup for static interfaces to run
in the constructor, and for dynamic initialization in `pruneInterface`,
getting rid of partial initializations in `init`.
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.
To move a task instance to another one, it's not sufficient to swap all task members,
but we also need to adapt all back pointers, i.e. me_ and parent_ pointers of children,
to point to the (swapped) task instances.
- to allow solution wrappers (WrappedSolution, SolutionSequence)
to transmit their comment and markers as well
- introduced new SolutionInfo.msg,
which is the info common to solution wrappers and actual SubTrajectories
Reworked cost_queue to correctly sort pointer-like types.
Added unittests for new ValueOrPointeeLess<T> less operator, ordered<T>, and rviz cost ordering.
Provide TaskPanel::addSubPanel() to add new sub panels.
Each panel can be activated with an associated QToolButton.
Sub panels, derived from base class SubPanel, automatically load/save their config settings.
All settings are shown in GlobalSettingsWidget (renamed from TaskSettings).
To allow stages to display their properties in a custom fashion, e.g.
to show the end-effector marker for PoseStamped, we need to be able
to register stage-specific factories.
- solutions_, failures_ as SolutionBaseConstPtrs in StagePrivate
- replace processSolutions() / processFailures() by direct const-access to storage containers
- generic sendForward(), sendBackward(), spawn(), connect() methods in StagePrivate
- reuse StagePrivate's sendForward(), sendBackward(), spawn() in containers
- store created InterfaceStates in StagePrivate::states_
- Interface: ordered<InterfaceState*> (only store pointers)
allows for common handling of states of valid and failure solutions
- remove additional state+solution storages
- containers: internal->external state mapping as InterfaceState* -> InterfaceState*
- code simplification
- allow slider interaction at any time
- keep last frame visible if animation finished
- animating_ is true iff animation is running
(previously it was also used to indicate the end of an animation cycle)
- renamed showMarkers() -> addMarkers()
- MarkerVisualizationProperty: renamed visible_markers_ -> hosted_markers_
Hosted markers are not neccessarily visible,
only if the corresponding namespace group is enabled.
- store "failure" solutions to facilitate debugging
- Introspection assigns solution IDs as soon as they are created in a stage
Thus, solution IDs represent their creation order.
In contrast, the order of publishing (in StageStatistics) should
represent the cost order.
- Storing failures is disabled if Introspection is not available.
The task id was not unique enough to distinguish different tasks.
When a task publisher is killed and restarted, it usually comes up with
the same task id. However, visualization doesn't notice this change and
get confused / crashes when receiving task statistics and solutions.
- only attempt to retrieve solution if remote was not yet destroyed
- setting get_solution_client is neccessary only once (pointer never changes)
- more reliable topic handling + status feedback
- locking: suppress interrupting current solution display when navigating solutions
- display end scene at the end of a solution display
- allow to display multiple solutions (its markers)
All scene nodes are hidden if
- there is no solution to display
- or if animation finished and neither the panel nor the trail are enabled
Hiding scene nodes is done by detaching them from their parent
- make TaskStatistics a latched topic too
- subscribing to topics in order (1. description, 2. statistics, 3. solution)
should ensure that we receive those latched messages in this order