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.
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
I assume we have to use actionlib_msgs to be consistent with its defination as we also use
self.client.get_status()
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]:
move_drone()
rate.sleep()
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!")