My previous patches accidentally disabled *all* (3) reset messages,
instead of keeping exactly one. This patch sends exactly one empty description
(reset) message every time an introspection instance is constructed for a task.
Notice the additional increase of the description queue_size from 1 to 2 to avoid
directly dropping the reset message in favor of the new description likely to be send
shortly afterwards.
Otherwise a new task will always setup the publisher,
even if introspection is disabled afterwards.
It is a good idea to keep introspection on, but there should be a way to initialize the C++ classes without ROS communication.
So far, the start_scene field of a SolutionMsg was only filled by Introspection::fillSolution(),
but not yet by Task::execute().
Addendum(v4hn): The previous approach was actually reasonable too (although the scene should have been marked as `is_diff`) for solutions sent for execution, but keeping the full start_scene around can facilitate debugging from recorded data.
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.
Validate interfaces during resolution. No need to separately validate interfaces.
Thus, validateConnectivity() is removed from Task::init().
Functions are kept (but simplified) for unit testing.
* Do not modify explicitly configured direction of Propagator
* Avoid code duplication in pruneInterface() and validateConnectivity()
Only implement pruneInterface() for stages that actually need to adapt their interface.
* Enforce at compile time that either input or output flags are considered.
* Use horizontal flow symbols (as in console output).
* Replace redundant direction(flags).
* Reset mock_id for each test to facilitate assignment
* Simplify creation of nested containers
* Moved some test cases around
* Output all exception messages (even expected ones)
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`.
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.
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.
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.
We need to distinguish two cases for how the interface of a nested serial container is determined:
1. from its children
2. from its (outer) context
As long as the interface is not fully resolved, requiredInterface() returns UNKNOWN.
After pruning, the first/last child's interface is remembered and reported instead.
If PropagatingEitherWay's interface is not met in *both* directions (but only one),
in BOTHWAY mode, issue a warning. Otherwise handle both, AUTO and BOTHWAY mode,
in the same fashion when resolving interfaces.
TODO: move validateConnectivity() in StagePrivate.
default action = default action from ContainerBase.
PropagatingEitherWay: issue warning for case above
- 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.
This is not a good approach.
The same can be achieved by generating targets incrementally.
The better approach, to generate IK solutions incrementally,
has to maintain previous solutions for each target.
Release mode builds previously produced broken solutions with too many entries,
debug build triggered the assert
container.cpp:334: assert(solution.empty())
The standard guarantees std::vector(&&a) leaves a.empty() == true,
so the logic there is fine as long as subsolutions is actually
used for move-construction.