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.
* 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`.
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.
"Goal" implies a motion to a target configuration.
MoveRelative explicitly does not do that.
"Direction" is usually not used for rotations,
but perfectly valid to describe them.
I merged 544f574166
together with the first version of this rename
that got force-pushed because it was incomplete.
- remove group + timeout properties: they are passed as arguments to plan()
- move max_velocity_scaling_factor, max_acceleration_scaling_factor to PlannerInterface base class
These branches only work together:
- MoveTo / MoveRelative: common handling of "goal" property
- properties: required changes to allow for multiple inheritance
- generalize SimpleGrasp / GenerateGraspPose
- source_id -> source_flags: bits indicating configured paths
- initializers, e.g. fromName(), should throw
- ignore undeclared errors during inheritance
- on undefined error, reset the value to None
- override value only if previously set by lower-priority source
MANUAL > CURRENT > PARENT > INTERFACE
- remove bool return value
- always create a solution trajectory, also in case of failures
- success/failure determined from solution.isFailure()
minor adjustments during cherry-pick