Introduce Action and SceneState

[yck011522]

This pull request is to introduce the Action and State Classes for modeling a robotic fabrication process. The concept of Actions and States is based on this paper https://dl.acm.org/doi/abs/10.1145/3485114.3485122. Actions and SceneStates are related tightly because an Action is conceptually the object that would change the current state to a new state.

There is generally a distinction between robotic actions vs non-robotic actions. The difference is that the robotic ones require motion planning, which is fulfilled by the motion planning backend of compas_fab. The distinction is implemented by inheriting from the RoboticAction class. A number of common Actions are provided in the compas_fab library, but users are free to implement their own actions according to the needs of their process and the function of their tools.

In any robotic process, the initial state is described with SceneState object. It contains the state of all the mutable properties of objects in the planning scene. The objects include RobotState, ToolState (multiple), and WorkpieceState (multiple). The default implementation of these objects contains a minimal set of properties. For example, WorkpieceState contains the location (Frame) of the workpiece. Users can inherit these as base classes and add more properties if needed. In addition, the SceneState contains information describing tool attachment (to Robot) and workpiece attachment (to Tool). See API of SceneState for more details.

As actions are performed (or applied in simulation), they influence the state of the scene, resulting in a new scene state. The new scene state can be used to describe the beginning of the next action and so on. This function to modify a starting state to create an ending state is encoded using the function Action.apply_to(self, scene_state,). This function allows automatic parsing of all intermediate states once the (1) initial state and (2) action list are created. This allows the user to visualize the scene, where object locations and attachment relationships can be examined. This visualization can happen even before motion planning and can help identify incorrect modeling that may cause motion planning failure.

During motion planning, the planner is preloaded with all the object models. The input to plan a single RoboticAction is the starting scene state and the RoboticAction object. In special cases where non-sequential planning is required, the SceneState at the beginning of any action can be computed automatically, allowing a single Action to be planned out of sequence. See Tutorial: Non-Sequential Planning (not yet written) for more details.

After motion planning, the planned trajectory will be stored in the same Action object. Which can be used for visualization and execution.

What type of change is this?

• Bug fix in a backwards-compatible manner.
• New feature in a backwards-compatible manner.
• Breaking change: bug fix or new feature that involve incompatible API changes.
• Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
• I ran all tests on my computer and it's all green (i.e. invoke test).
• I ran lint on my computer and there are no errors (i.e. invoke lint).
• I added new functions/classes and made them available on a second-level import, e.g. compas_fab.robots.CollisionMesh.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if appropriate)

[yck011522]

Link to compas-dev/compas#1209 for potential synergy.

[yck011522]

@gonzalocasas @chenkasirer Will you have time to take a look at this?

[gonzalocasas]

It's looking good! I added a bunch of feedback, the only thing that really worries me is the lack of support for multiple robots, which I feel might be an impossible thing to add in the future, so, as mentioned, let's chat about it soon and see what are the options.

[yck011522]

Lets hold on to resolve the Targets #409 before going back to this one.