The preempt_request_ flag was only checked at the top-level task container before each compute iteration.
As a single sweep might take a while, we should check the flag before computing each stage.
Calling preempt() before plan() is able to reset the preempt_requested_ flag causes the preemption request to get lost. To avoid this issue, we allow a) manual resetting of the request and b) reset the request before leaving plan().
... to illustrate that MoveRelative's min-max constraint fails with PipelinePlanners (e.g. Pilz) returning a partially invalid trajectory: MTC does not truncate the trajectory to its valid part and thus fails, even if the valid part fits the given min-max range. This logic is only supported for the CartesianPath planner for now.
Co-authored-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
When adding pending state pairs for a new incoming state to Connect,
we have to re-enable opposite states from ARMED state.
This changes the order of states in the interface.
If we do this while iterating over the states, we might add pairs multiple times,
because iteration continues with same state at an earlier position.
- Add Stage::introspection() accessor
- Introspection: debug-log solution registration
- RemoteSolutionModel: show internal solution id as tooltip in 1st column
If two Connect stages are sequenced, both sides can become ARMED.
However, that means that the wave of PRUNED status updates, shouldn't
overwrite a present ARMED state.
Added unit test.
Let's consider the following simple situation, where generators produce solutions in the given order.
GEN 1 3
Fallbacks |X
GEN 2 4
When passing state 4 to the Fallbacks' connector, it forms pending pairs with both 1 and 3.
Thus, the container needs to check whether 1-4 or 3-4 was processed when receiving a success or failure,
to correctly forward the failed one to the next child.
- Enable moving/swapping of other container impls (e.g. Fallbacks)
- Clarify (via move semantics) that content of source impl will be lost
- Get rid of friend declarations
Adapt test results FallbacksFixturePropagate.computeFirstSuccessfulStagePerSolutionOnly
due to 2e63c154aa:
The order of computations has changed, because we lock the processed state
as soon as it is forwarded to the first fallback child.
In this case, after processing GEN1 und FWD1 once, we have the two states with costs 2, 4 in the queue.
The first one, i.e. with cost 2 is forwarded to the child FWD2, which fails.
In the next cycle, although we have new states in the queue (1, 2, 3, 4), we stick with state "2"
and forward it two FWD3, which adds costs 210, resulting in 212.
With previous code, the Fallback container switched to state "1", forwarded to FWD2.
Not only propagate updates along solution paths, but also bridge
the gap of a `Connecting` stage.
- If a state becomes enabled, re-enable opposite `ARMED` states as well.
- If a state becomes pruned, also prune opposite states if they don't have alternatives.
- Make sure that we don't run into a recursive update loop by disabling notify() callbacks.