Why do you use customized, simplified goal status instead of the predefined status in actionlib_msg?

In the solution of exercise8.6 of the action section

# We create some constants with the corresponing vaules from the SimpleGoalState class
DONE = 2
WARN = 3

However, these are not very compatible with the predefined goal status in the actionlib_msgs

Why not import and use the standard predefined status?

 0 ==> PENDING 
1 ==> ACTIVE 
4 ==> ABORTED 
9 ==> LOST

Thanks for the feedback. We’ll take a look.

Hi Min,
you are right. At some point in time, the status messages changed from the simple 5 states we included in the solution, to the 10 states you indicated in the actionlib_msgs link.

So the logic of the solution should be changed according to that new definition of the status codes.

Actually, in order to prevent those errors from happening again, the solution should check for the actionlib_msgs defined uint8 instead that check for specific numbers.

This means, do the check as follows:

while state_result < GoalStatus.DONE:

By doing it like that, you do not have to redefine the statuses and use directly the ones that are defined in the official actionlib_msgs definition.

We are correcting the solution along this week to reflect those changes. I apologize for the inconvenience.

Hi Rtetete,

Thank you for your reply!
Do you mean the actionlib updated the status defination from 5 to 10 and the solution of the Construct course used the numbers directly?
I feel confused about the customized version as they are just numbers and are even not consistent with actionlib. The main question is can we redefine these statuses like this? As we create the client by

self.client = actionlib.SimpleActionClient(self.action_server_name, ArdroneAction)

I assume we have to use actionlib_msgs to be consistent with its defination as we also use


By the way, actually I cannot not find Done. That’s why I checked it. I assume the old solution might cause errors, right?

Here is my solution:

   while state_result in [GoalStatus.PENDING, GoalStatus.ACTIVE, GoalStatus.PREEMPTING]:
            state_result = self.client.get_state()
            rospy.loginfo('Moving around...')
            rospy.loginfo("state_result: " + str(state_result))

        rospy.loginfo("[Result] State: " + str(state_result))
        if state_result == GoalStatus.ABORTED:
            rospy.logerr("Something went wrong in the Server Side")
        if state_result == GoalStatus.REJECTED:
            rospy.logwarn("The goal was rejected by the Server")
        if state_result == GoalStatus.SUCCEEDED:
            rospy.loginfo("Goal succeeded!")

I think he means SUCCEEDED.Yes, the solution might cause errors.

Your while condition is technically the same as

while state_result < GoalStatus.SUCCEEDED:
1 Like

Ha ha ha yes, sorry I meant GoalStatus.SUCCEEDED (just got carried away by the previous code).

Bayode’s response is correct

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.