NASA-AMMOS
Ability to "Group" Activities Linked via Scheduling
Checked for duplicates
Yes - I've already checked
Alternatives considered
No - I haven't considered
Related problems
This is somewhat related to the issue found with the activityFinder (https://github.com/NASA-AMMOS/aerie/issues/1061). If the ability to group scheduled activity instances and space them out from other distinct groupings was available this activityFinder bug would be a more minor problem.
Describe the feature request
When scheduling groupings of activity instances together it would be helpful to have the option to prevent that "group" from overlapping with other "groups" (via group mutexes or a new global scheduling condition). There are many instances where one scheduling goal sets up GNC turns and array articulations surrounding a primary instrument activity instance. When setting these up in a larger plan, in many cases we want these groupings to not overlap with other goal's groupings that involved GNC/array articulations.
Currently, mutexes can be written to prevent overlap of the GNC and array activity types, but it would be beneficial to have the capability to write mutexes preventing overlap of scheduled groupings of activity instances relative to one another. Similarly, being able to set spacing preferences between scheduled groupings would aide significantly in planning (i.e. allow 30 minutes on either end of X grouping from other groupings). This could potentially be handled with a global scheduling condition and would help break up spacing of linked activities in the plan.
A workaround that was put in place to build Clipper's Thread Test 6 plan was to shift the applyWhen window for select anchor activity placements to X hrs after a notable event (in TT6 the >2AU transition) instead of leaving the goal with simply the true constraint (>2AU). This was to space out the scheduled activity groupings to fall in a more logical ordering along with buffer time in between groups.
Slides with design approach for groups Grouping.pptx
Need to discuss:
- How to store compound activities. Involvement from DB recommended
- How to enable users to re-use compound activities. Involvement from user interface team recommended
@jmdelfa and others met yesterday to discuss the details of this + HTNs, detailed notes in Slack here:
https://jpl.slack.com/archives/CJ07FGRPH/p1701910742191329
This is related to #1364 and we'll discuss more next week to scope both of them together.
Here is a summary of the current design:
- Ordering: Partial order must be supported. Trivial case with full order might be deliver in a first MVP
- Planning expressiveness: No pre/post conditions. Notice that partial support to it is being developed via VIOLET
- Compound Activity role:
- Abstract; hence compound activities don’t need to be executed
- Scheduler can schedule them (via unary goals). A task network is a compound activity, with the difference that a compound activity is not decomposed, and a task network is •To be decided: Considering that a task network can be implemented as a compound task: Does the compound task remain on the plan, or is replaced by the task network? My current thinking is that a plan just have the compound task, which may not be decomposed or decomposed, in which case it also has a task network. In this way, all what the decomposer and scheduler see are goals containing activities upon which they have to act (plan or schedule).
- Scheduling approach: Early commitment
- Cycles: Not allowed. There is a maximum depth and child activities cannot decompose into parent activities. That is, the activity structure is a tree, not a graph
- Type of constraints: The task network should allow for Allen temporal constraints. Parameter constraints discarded for first MVP
- Goals: Inclusion of unary goal. Compound activities are encapsulated into unary goals.
- Task Nets: Align exclusively decompositions. Rest of divergences with task networks out of scope of this issue.
- Mission Model: Will be expanded to contain Task Networks (list of activities and constraints) and Methods (link each compound task to task networks that decompose it)
The new Aerie workflow would be: 1.User creates a (partial) plan potentially including compound activities. 2.To generate a valid plan, the user clicks in Plan&Schedule 3.The Decomposer proceeds to decompose compound activities, one at a time. Each subactivity is encapsulated as a unary goal. The resulting partial plan, including goals and constraints is sent to the scheduler 4. The scheduler then schedules all sub-activities (compound or primitive) while satisfying the constraints. There are three outcomes of the scheduling step: 4.1 The scheduler has found a solution and the decomposer decomposed all compound activities: A solution is returned to the user 4.2 The scheduler has found a solution but the decomposer didn’t decompose all activities: Partial plan is sent back to decomposer 4.3 The scheduler couldn’t find a solution: An error is returned to the user
Should we keep all design stuff in the discussion instead of this ticket ? I have added impl notes/questions there instead of here.
