Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the start state of most composite instructions (especially nested composite instructions) are never changed from
NullInstructions
. The reason for this is that usually the start instruction of one composite usually duplicates the last instruction of the previous composite, such as in the case of a robot trajectory. To avoid duplicating waypoints, the start instructions of most subsequent composites are left empty. However, this can be problematic when trying to use a nested composite instruction as a seed for another instruction or when using the composite instruction on its own. It also makes the composite instruction confusing to interpret since it is missing its first waypoint.This PR updates the instruction
flatten
functions to ignore start instructions from composites that are not the first in a container. This retains the current behavior for the assembly of trajectories from nested composite instructions. This PR also changes the simple planner utilitygetInterpolatedComposite
to put the first state of the interpolation as the start instruction of the composite, such that the entire interpolation is captured in the composite instruction.This change is required for the OMPL planner refactor in #138