Have you seen and played with the scoped and forwarding options?

If I change the GroupAction to

    my_group_action = GroupAction(
        actions=[nested_launch],
        scoped = False,
    )

it works. I still don't understand why. Could you explain a bit more about the concepts of scoped and forwarding? Is it about separating everything inside the GroupAction from everything outside or is it about separating the actions inside the GroupAction from each other? (From my understanding, separating the inside and outside of the GroupAction would make more sense.) Keep in mind, that the TimerAction and DeclareLaunchArgument are within the IncludeLaunchDescription, which is itself inside the GroupAction. So everything is inside the GroupAction. Even if it was separated from the outside, it should still be in the same scope as DeclareLaunchArgument and at least get the argument with its default value.

I understand the concept as followed: With the default settings (scoped=True and forwarding=True) the actions inside should be in its own scope, so that e.g. setting environment variables inside the GroupAction has no effect outside. Because of forwarding, you should still have access (read access?) to everything, that was defined outside of the GroupAction. Are these assumptions correct? This would not explain the error and it should work with the default settings, right?

I'm sorry, I haven't had time to properly dig into this. I'm hoping to do it by tomorrow.

Sorry again for the delay.

So I believe your understanding of the GroupAction's scoping and forwarding is correct, and that you should indeed not have to use scoped=False. However, your assumption about the TimerAction is unfortunately incorrect in practice.

I believe this a bug -- or at least a not-well-defined case -- with TimerAction. TimerActions's actions, in this case its Node, are only executed after the given period, which is 2.0 seconds in this case. This means that the substitution for the launch configuration used for the node's namespace (LaunchConfiguration('robot_namespace')) is only resolved (or "performed," as it's called in launch) then. By this point, the GroupAction's scoping feature has effectively reset the launch configurations, unless you disable scoping.

TimerAction already "saves" some of the launch context's data before it creates the timer so that it can be used later, when its actions execute:

1. Save before creating the timer task:

   launch/launch/launch/actions/timer_action.py

   Line 193 in 151b024

   self.__context_locals = dict(context.get_locals_as_dict()) # Capture a copy

2. Restore before the actions are executed:

   launch/launch/launch/actions/timer_action.py

   Line 141 in 151b024

   context.extend_locals(self.__context_locals)

If I do something similar for the launch context's launch configurations, then your original launch file works, without needing scoped=False:

diff --git a/launch/launch/actions/timer_action.py b/launch/launch/actions/timer_action.py
index ac9049c..863a07d 100644
--- a/launch/launch/actions/timer_action.py
+++ b/launch/launch/actions/timer_action.py
@@ -139,6 +139,7 @@ class TimerAction(Action):
     def handle(self, context: LaunchContext) -> Optional[SomeEntitiesType]:
         """Handle firing of timer."""
         context.extend_locals(self.__context_locals)
+        context.launch_configurations.update(self.__context_launch_configuration)
         return self.__actions
 
     def cancel(self) -> None:
@@ -191,6 +192,7 @@ class TimerAction(Action):
 
         # Capture the current context locals so the yielded actions can make use of them too.
         self.__context_locals = dict(context.get_locals_as_dict())  # Capture a copy
+        self.__context_launch_configuration = dict(context.launch_configurations)  # Capture a copy
         context.asyncio_loop.create_task(self._wait_to_fire_event(context))
 
         # By default, the 'shutdown' event will cause timers to cancel so they don't hold up the

I think this fix makes sense, but let me double-check and add a test, too.

@M-Schroeder see #836. If you could give it a try and let me know if it works for you and if the changes to the TimerAction's behaviour make sense to you, that would be helpful.

I tried the corresponding changes in ROS2 humble and it now works for me. Your explanation makes sense and the proposed behavior seems more intuitive. (Unfortunately, I am not familiar enough with this repo to understand everything of the code and your changes)
Thank you very much for the help