Get_state() responses are incorrect

[rbed23]

After the exercise 7.4a Explanation in Course 8: “Understanding ROS Actions” it states:

How to perform other tasks while the Action is in progress

You know how to call an action and wait for the result but… That’s exactly what a service does! Then why are you learning actions?
Good point!

So, the SimpleActionClient objects have two functions that can be used for knowing if the action that is being performed has finished, and how:

1. wait_for_result(): This function is very simple. When called, it will wait until the action has finished and returns a true value. As you can see, it’s useless if you want to perform other tasks in parallel because the program will stop there until the action is finished.

2. get_state(): This function is much more interesting. When called, it returns an integer that indicates in which state is the action that the SimpleActionClient object is connected to.

0 ==> PENDING
1 ==> ACTIVE
2 ==> DONE
3 ==> WARN
4 ==> ERROR

This allows you to create a while loop that checks if the value returned by get_state() is 2 or higher. If it is not, it means that the action is still in progress, so you can keep doing other things.

I found it odd, bc my script was returning <3> after a successful execution of the script.

Digging into the ActionLib materials, I found the correct enumeration language in the actionlib_msgs/msg/GoalStatus.msg file…

user:/opt/ros/kinetic/share/actionlib_msgs$ cat msg/GoalStatus.msg
GoalID goal_id
uint8 status
uint8 PENDING         = 0   # The goal has yet to be processed by the action server
uint8 ACTIVE          = 1   # The goal is currently being processed by the action server
uint8 PREEMPTED       = 2   # The goal received a cancel request after it started executing
                        #   and has since completed its execution (Terminal State)
uint8 SUCCEEDED       = 3   # The goal was achieved successfully by the action server (Terminal State)
uint8 ABORTED         = 4   # The goal was aborted during execution by the action server due
                        #    to some failure (Terminal State)
uint8 REJECTED        = 5   # The goal was rejected by the action server without being processed,
                        #    because the goal was unattainable or invalid (Terminal State)
uint8 PREEMPTING      = 6   # The goal received a cancel request after it started executing
                        #    and has not yet completed execution
uint8 RECALLING       = 7   # The goal received a cancel request before it started executing,
                        #    but the action server has not yet confirmed that the goal is canceled
uint8 RECALLED        = 8   # The goal received a cancel request before it started executing
                        #    and was successfully cancelled (Terminal State)
uint8 LOST            = 9   # An action client can determine that a goal is LOST. This should not be
                        #    sent over the wire by an action server

#Allow for the user to associate a string with GoalStatus for debugging
string text

Showing that <3> from a client.get_state() method call means “Succeeded”

This should be updated in the course language.

[roalgoal]

Hi, thank you fro bringing this to our attention. We will change this in the course

[Joakimmf]

This does not seem to have been fixed for the example code provided (now for exercise 8.5b), it still has that incorrect list in the code, and uses it to determine outputs
Thus it automatically enters
if state_result == WARN:
rospy.logwarn(“There is a warning in the Server Side”)
Even though there is now warning, because the WARN it’s matching against actually corresponds to SUCCEEDED

[Joakimmf]

This is an error report.

---

Screenshot of the error

---

Error details

like 8.5b, the map of numbers to meanings in the provided code is incorrect, Done is mapped to 2, even though Succeeded is 3, and 2 is Preempted this is especially noticeable in this case, since if the numbers were actually mapped correctly the code would get stuck in a strange infinite loop where canceling the action still waiting for the action to complete (since it waits for get_state to output 3 or higher, and preempted is 2)

[bayodesegun]

I apologize for the delay in fixing this. We must have missed this. We’ll prioritize it for fixing now.