Add SequentialTaskBase class #289

peterd-NV · 2025-12-12T17:20:04Z

Summary

This PR adds initial support for composite sequential tasks via the SequentialTaskBase class. The SequentialTaskBase class takes a list of atomic tasks (TaskBase) and automatically assembles them into a composite task with unified termination/event configs.

Adds:

SequentialTaskBase class
Test case to validate class methods
Test case with example task (sequential open door task) to validate unified success check and events
Two new functions in isaac_arena/utils/configclass.py to perform config transformation and duplicate checking

…d/sequential_task_base

isaaclab_arena/tests/test_sequential_open_door.py

xyao-nv · 2025-12-16T05:19:03Z

LTGM. Maybe can think about how to get rid of those for env_id in env_ids loop in the future.

isaaclab_arena/tasks/sequential_task_base.py

alexmillane

Really great work. This is going to be a big upgrade in capabilities.

I have a few comments. Happy to take another look!

alexmillane · 2025-12-16T08:46:13Z

isaaclab_arena/tasks/sequential_task_base.py

+    A base class for tasks composed sequentially from multiple subtasks.
+    The sequential task takes a list of TaskBase instances (subtasks),
+    and automatically collects configs to form a composite task.


Suggestion to expand the definition of a sequential task. I guess "sequential" is a specific form of composite, in that the atomic tasks must be completed in order, one after another. Once completed, a sub-tasks can then go back to being not-true, and the sequential task still completes. This is in contrast to something like a composite task where atomic tasks can be completed in any order, or a task where all atomic tasks must be true at once.

Good point, I've expanded the description with a more detailed definition to what "sequential" here means

alexmillane · 2025-12-16T08:47:43Z

isaaclab_arena/tasks/sequential_task_base.py

+    @staticmethod
+    def _add_suffix_to_configclass_fields(cfg_instance: Any, suffix: str) -> Any:
+        """Create a new configclass instance with all field names appended with a suffix."""
+        if cfg_instance is None:
+            return None
+
+        fields = dataclasses.fields(cfg_instance)
+        new_fields = []
+        field_values = {}
+
+        # Rename the fields with suffix
+        for field in fields:
+            new_name = f"{field.name}{suffix}"
+            value = getattr(cfg_instance, field.name)
+            new_fields.append((new_name, field.type, value))
+            field_values[new_name] = value
+
+        # Create a new configclass with renamed fields
+        new_cfg_class = make_configclass(type(cfg_instance).__name__, new_fields)
+        return new_cfg_class(**field_values)


Suggestion to move this to isaaclab_arena.utils.configclass. We have a few other utilities in that file for modifying config classes.

See comment below on move to unified configclass transform func.

alexmillane · 2025-12-16T08:53:02Z

isaaclab_arena/tasks/sequential_task_base.py

+    @staticmethod
+    def _remove_configclass_fields(cfg_instance: Any, exclude_fields: set[str]) -> Any:
+        "Remove all fields from the configclass instance that are in the exclude_fields set."
+        if cfg_instance is None:
+            return None
+
+        fields = dataclasses.fields(cfg_instance)
+        new_fields = []
+        field_values = {}
+
+        # Remove the fields that are in the exclude_fields set
+        for field in fields:
+            if field.name in exclude_fields:
+                continue
+            value = getattr(cfg_instance, field.name)
+            new_fields.append((field.name, field.type, value))
+            field_values[field.name] = value
+
+        if not new_fields:
+            return None
+
+        # Create a new configclass without the excluded fields
+        new_cfg_class = make_configclass(type(cfg_instance).__name__, new_fields)
+        return new_cfg_class(**field_values)


As above, suggestion to move this to isaaclab_arena.utils.configclass.

Additionally, the two functions above have a very similar form. They loop through the fields, build a new config class by performing some mutation on each field. I wonder if we could write them in terms of a function transform_config_class which takes a Callable, loops through the fields, calling the callable on each and adding the resulting field to a new configclass if the return is not None.

Agree with that. Moving to to a generic "transform_config_class" function would be cleaner and more reusable by other parts of the code down the line. I've added the following:

A transform_configclass_instance function inside of utils/configclass.py. This function performs the "loop" seen in the original functions and takes a Callable to perform the transform

Added simple Callables in the SequentialTaskBase class to perform the transforms

Updated SequentialTaskBase class tests to use this format

alexmillane · 2025-12-16T09:16:56Z

isaaclab_arena/tasks/sequential_task_base.py

+        success = TerminationTermCfg(
+            func=self.sequential_task_success_func,
+            params={
+                "task_instance": self,
+            },
+        )


I find this construction of a static method which takes self a bit unexpected. Arguably the defining characteristic of a static method is that it doesn't take self.

Is it possible that we make sequential_task_success_func non-static, and then do

from functools import partial ... success = TerminationTermCfg( func=partial(SequentialTaskBase.sequential_task_success_func, self) )

We can then simplify SequentialTaskBase.sequential_task_success_func, as it will have the form of a normal method, with accecss to self etc.

Maybe there's something I'm missing?

Mmm I think setting the success/event functions to be non-static and use "self" would present an issue with other parts of Lab. Namely in some scripts like data recording, robomimic replay, mimic etc, they extract and use these functions directly to take full control of the env. For those, they depend on having the termination/event functions follow the standard function signature for Lab which is something like func(env, params...). If we define these as normal class methods then it would cause an issue with a lot of downstream scripts.

In the current setup, the "self" that is passed to this function is essentially a copy of the as Lab makes a deep copy of all configs before instantiating the managers. However, I do agree that it's really not ideal to be passing "self" to a static method.

I've made some changes which preserves these functions as staticmethods to keep the standard Lab function signature, but changed the argument to be the list of subtasks instead of an instance of SequentialTaskBase so that it's not directly using a copy of "self". What do you think of this solution?

Thank you for the explanation. I hadn't considered that Lab expects a certain signature.

With that said, I feel that the using partial should result in the correct signature no?

Maybe I'm mistake but I thought that:

class MyClass: def my_method(self, env, param) my_class = MyClass() my_partial = partial(my_class.my_method, self)

results in my_partial having the signature of func(env, param). Perhaps I'm mistaken.

With all of that said. Let's merge this all is. It's not that important.

alexmillane · 2025-12-16T09:22:29Z

isaaclab_arena/tasks/sequential_task_base.py

+        "Make combined scene cfg from all subtasks."
+        scene_cfg = combine_configclass_instances("SceneCfg", *(subtask.get_scene_cfg() for subtask in self.subtasks))


I wonder if we should add something in isaaclab_arena.utils.configclass to detect if there are repeated config class members. Here we could check and warn (before proceeding).

Make's sense, I've added a function to utils.configclass to scan and return any duplicates: check_configclass_field_duplicates

If duplicates are found it'll give users a warning showing the names of them.

isaaclab_arena/tests/test_sequential_open_door.py

alexmillane · 2025-12-16T10:15:53Z

isaaclab_arena/tests/test_sequential_task_base.py

+if __name__ == "__main__":
+    test_add_suffix_to_configclass_fields()
+    test_remove_configclass_fields()


isaaclab_arena/tasks/sequential_task_base.py

…d/sequential_task_base

peterd-NV · 2025-12-16T21:12:49Z

Thanks for the great feedback @alexmillane @xyao-nv. I've pushed new changes that address each comment. Please take a look to see if you have any further comments.

…d/sequential_task_base

alexmillane

LGTM!

alexmillane · 2025-12-17T15:15:36Z

isaaclab_arena/tasks/sequential_task_base.py

+        success = TerminationTermCfg(
+            func=self.sequential_task_success_func,
+            params={
+                "task_instance": self,
+            },
+        )


Thank you for the explanation. I hadn't considered that Lab expects a certain signature.

With that said, I feel that the using partial should result in the correct signature no?

Maybe I'm mistake but I thought that:

class MyClass: def my_method(self, env, param) my_class = MyClass() my_partial = partial(my_class.my_method, self)

results in my_partial having the signature of func(env, param). Perhaps I'm mistaken.

With all of that said. Let's merge this all is. It's not that important.

isaaclab_arena/tests/test_sequential_open_door.py

isaaclab_arena/utils/configclass.py

viiik-inside

Really cool!

peterd-NV added 8 commits December 12, 2025 07:12

add sequential task base class

3ae6a26

formatting

ab4a9c7

update licence

604fff3

add tests

b276aea

formatting

2bb4d62

clean up naming

06e965b

update sequential task base test

93eacb5

Merge branch 'main' of github.com:isaac-sim/IsaacLab-Arena into peter…

a1c8cb7

…d/sequential_task_base

peterd-NV marked this pull request as ready for review December 15, 2025 17:39

peterd-NV changed the title ~~Draft: Add SequentialTaskBase class~~ Add SequentialTaskBase class Dec 15, 2025

xyao-nv reviewed Dec 16, 2025

View reviewed changes

isaaclab_arena/tests/test_sequential_open_door.py Show resolved Hide resolved

xyao-nv reviewed Dec 16, 2025

View reviewed changes

isaaclab_arena/tasks/sequential_task_base.py Show resolved Hide resolved

alexmillane reviewed Dec 16, 2025

View reviewed changes

peterd-NV added 6 commits December 16, 2025 07:49

Merge branch 'main' of github.com:isaac-sim/IsaacLab-Arena into peter…

5268766

…d/sequential_task_base

update PR according to review comments

3cf48af

format

d98385d

add comment for removing reset event

1cd2928

add todo comments for Mimic/Metrics configs

30291aa

update open door seq task test with two microwaves

6e506a8

peterd-NV requested review from alexmillane and xyao-nv December 16, 2025 21:13

Merge branch 'main' of github.com:isaac-sim/IsaacLab-Arena into peter…

c46186c

…d/sequential_task_base

alexmillane approved these changes Dec 17, 2025

View reviewed changes

viiik-inside approved these changes Dec 17, 2025

View reviewed changes

peterd-NV merged commit 3b1f31a into main Dec 17, 2025
5 checks passed

		"Make combined scene cfg from all subtasks."
		scene_cfg = combine_configclass_instances("SceneCfg", *(subtask.get_scene_cfg() for subtask in self.subtasks))

Add SequentialTaskBase class #289

Add SequentialTaskBase class #289

Uh oh!

Conversation

peterd-NV commented Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

Uh oh!

xyao-nv commented Dec 16, 2025

Uh oh!

Uh oh!

alexmillane left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

peterd-NV commented Dec 16, 2025

Uh oh!

alexmillane left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

viiik-inside left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

peterd-NV commented Dec 12, 2025 •

edited

Loading