ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

No transition matching 3 found for current state

asked 2021-07-28 08:29:00 -0500

bergercookie gravatar image

updated 2021-07-28 08:31:45 -0500

I'm looking at the ros2 lifecycles demo here: https://github.com/ros2/demos/blob/fo...

According to the Lifecycles page of ROS2 if an exception occurs in any of the primary states then the on_error method should be called, which in turn, on SUCCESS reverts to the Unconfigured state, and on FAILUREit goes to Finalized and eventually the node gets shutdown.

For the sake of the example I'll throw an exception from within one of the transition callbacks, e.g., on_activate.

on_activate(const rclcpp_lifecycle::State &)
{
  throw std::runtime_error("some_error");
  ...

With this change in place I see the following transitions happening (see roslaunch output of command ros2 launch lifecycle lifecycle_demo.launch.py)

[lifecycle_listener-2] [INFO] [1627469418.643524277] [lc_listener]: notify callback: Transition from state activating to errorprocessing
[lifecycle_listener-2] [INFO] [1627469418.643625385] [lc_listener]: notify callback: Transition from state errorprocessing to unconfigured
[lifecycle_service_client-3] [WARN] [1627469418.643600791] [lc_client]: Failed to trigger transition 3

I understand why it transitions to errorprocessing and then to unconfigured. However it then tries to transition to "3" which is the TRANSITION_ACTIVATE transition and it fails to do so since that is not a valid transition (Unconfigured -> Active)

I don't understand though, why is it trying transition to activate since I or any other node didn't explicitly trigger this transition? What can I do to solve this?

Here's also the full list of transitions the node goes through, in case it's helpful

ros2 topic echo /lc_talker/transition_event
timestamp: 0
transition:
  id: 0
  label: ''
start_state:
  id: 1
  label: unconfigured
goal_state:
  id: 10
  label: configuring
---
timestamp: 0
transition:
  id: 0
  label: ''
start_state:
  id: 10
  label: configuring
goal_state:
  id: 2
  label: inactive
---
timestamp: 0
transition:
  id: 0
  label: ''
start_state:
  id: 2
  label: inactive
goal_state:
  id: 13
  label: activating
---
timestamp: 0
transition:
  id: 0
  label: ''
start_state:
  id: 13
  label: activating
goal_state:
  id: 15
  label: errorprocessing
---
timestamp: 0
transition:
  id: 0
  label: ''
start_state:
  id: 15
  label: errorprocessing
goal_state:
  id: 1
  label: unconfigured
---

System Information

I'm using:

  • Ubuntu 20.04
  • Latest version of the PPA packages of ROS Foxy.

Any pointers?

edit retag flag offensive close merge delete

Comments

1

Not 100% sure, but something I noted - looking at the timestamps of the output you posted, the warning

[WARN] [1627469418.643600791] [lc_client]: Failed to trigger transition 3

actually happens before the transition to unconfigured

[INFO] [1627469418.643625385] [lc_listener]: notify callback: Transition from state errorprocessing to unconfigured

by some number of microseconds.

Does the process die after the warning, or can you query the lifecycle node's state manually? Could be that its just a bit of confusion due to the way the scheduler bundled the different logging processes?

shonigmann gravatar image shonigmann  ( 2021-07-28 11:07:54 -0500 )edit

Ah, yoiu're right! Nice catch!

Do you want to form it into an answer? I'd be happy to approve it

bergercookie gravatar image bergercookie  ( 2021-07-29 01:08:13 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2021-07-29 10:26:38 -0500

shonigmann gravatar image

[moving my comment down into the answers]

Looking at the timestamps of the output you posted, the warning

[WARN] [1627469418.6436**00791**] [lc_client]: Failed to trigger transition 3

actually happens before the transition to unconfigured

[INFO] [1627469418.6436**25385**] [lc_listener]: notify callback: Transition from state errorprocessing to unconfigured

by some number of microseconds.

If the process didn't die after the warning, it could be that its just a bit of confusion due to the way the scheduler bundled the different logging processes

edit flag offensive delete link more

Question Tools

3 followers

Stats

Asked: 2021-07-28 08:29:00 -0500

Seen: 930 times

Last updated: Jul 29 '21