Activity Grouping: Backend proof-of-concept

Description

@jmdelfa and @adrienmaillard have been working on implementing the classes & solver needed to support grouped activities with HTNs. As our next milestone, we'd like to build a backend-only proof of concept which implements grouping, so that we can test & understand its behavior separately from the ongoing UI implementation.

Requirements

To get this working we need:

An initial implementation of the necessary classes in the Merlin framework, so they can be used by the mission model (eg. CompoundActivityType, TasknetTemplate, etc)
A test mission model using the new framework code, implementing at least one CompoundActivityType that decomposes into primitive activity types as defined in a TasknetTemplate
A method for creating an Aerie plan using this model, which contains compound activity instances to be decomposed by the solver. The easiest way to do this might be with a plan.json file which can be imported into Aerie - or alternatively, if we're not sure how to represent compound activities in the plan file yet, it could be an empty plan + an API call which we run manually to insert the activity instances
An initial implementation of a solver in the Aerie scheduler which is capable of decomposing and "grounding" the compound activities when it is run

These should allow us to test the implementation of Grouping/HTNs independently from the UI.

Success Criteria

When this is done we should be able to perform a "thread test" of Grouping by:

uploading the test model + plan to Aerie
Running simulation + scheduler
Making an API query to see that the compound task has been correctly decomposed into primitive tasks with grounded times and values.

Related Issues

Subtask of Grouping task: #1073 UI task with more info: https://github.com/NASA-AMMOS/aerie-ui/issues/1375 Related GH Discussion: https://github.com/NASA-AMMOS/aerie/discussions/1451 Discussed with @jmdelfa in Sprint Planning 7/18/24

Current status: Core HTN classes - Developed.

They include: ActivityReference, Method, TasNetTemplate, TasNetTemplateData, TaskNetTemporalConstraint.

Example - Ongoing

I'm writing an example to understand what code should be generated.

Solvers

New solver approach consolidated. A new MetaSolver coordinates how to generate a plan. It extracts conflicts from the goals and the plan itself and send the conflicts and plans to solvers (decomposer or scheduler) in order to resolve them. For the moment, we assume decomposer only have one tasknet to decompose a compound activity. As a result of decomposition, new conflicts could be created. As a result of a failed schedule, the current plan is discarded

Note: Plan has been updated so that a new PartialPlan extends from Plan and includes conflicts and evaluation. Simulator doesn't care about this information and will use the base Plan class

Test Example

Writing an example on how the resulting generated code would look

Code generation

@adrienmaillard will work on the automatic generation of code

NASA-AMMOS / aerie