Error in node state when switching modes

[Juancams]

Hello!

I've been working with system_modes for a few days and I'm having an error when changing my system mode.

I have several modes, which are default, alert, compromised and halt, and in this particular example when I change the mode from alert to compromised there are nodes that do not change their status from active to inactive. I leave you images of the monitor so that you can see the result together with the yaml configuration of both modes.

ALERT:
        image_1_to_2: inactive
        imu_1_to_2: active
        odom_1_to_2: active
        pc2_1_to_2: active
        scan_1_to_2: active
        tf_1_to_2: active
        tf_static_1_to_2: active
        twist_2_to_1: active
COMPROMISED:
        image_1_to_2: inactive
        imu_1_to_2: active
        odom_1_to_2: active
        pc2_1_to_2: inactive
        scan_1_to_2: inactive
        tf_1_to_2: active
        tf_static_1_to_2: active
        twist_2_to_1: inactive

System in alert mode:

System in compromised mode:

I also show you how I have configured the modes of some of the nodes, although I am not using that parameter

pc2_1_to_2:
  ros__parameters:
    type: node
    modes:
      __DEFAULT__:
        ros__parameters:
          use_sim_time: false
      
scan_1_to_2:
  ros__parameters:
    type: node
    modes:
      __DEFAULT__:
        ros__parameters:
          use_sim_time: false

I do not have any type of rule configured, although I suppose that for this simple case of changing node states it would not be necessary.

Any idea what is happening?

[ralph-lange]

Hi @Juancams, apparently scan_1_to_2 did not switch to inactive. In this situation, can you check using ros2 lifecycle get /scan_1_to_2 whether scan_1_to_2 is really in active. If yes, can you test whether you can change it manually to inactive by ros2 lifecycle set /scan_1_to_2 deactivate and whether that's detected properly by the System Modes Monitor?

[Juancams]

Hi @ralph-lange , I'm sorry I didn't answer, I was on Christmas vacation.

I have verified what you tell me and it does transition. In this case, I am testing it on a real robot so some of the transitions are not immediate, but on simulated nodes that do nothing it gives the same error.

Something similar to what is discussed in this issue #94 happens to me, but in this case without using rules.

[Juancams]

Mentioning this issue again, when testing it, it is seen that what you do in the rules is patch the error that it has. When this error occurs, the system moves completely by default. If you remove the rules, it reproduces the same error as mine.