API review

Proposer: Eitan Marder-Eppstein and Vijay Pradeep

This is Take 3 of the API Review for actionlib. Since it looks like we're just ironing out the final last details in naming and such, we'll run this API review electronically. If we can't address all the issues via email/wiki, then we'll resort to scheduling a physical meeting.

The high level overview is available on the wiki: http://pr.willowgarage.com/wiki/actionlib

The actual API is available in doxygen. The relevant doxygen pages are linked to from the mainpage: http://pr.willowgarage.com/pr-docs/ros-packages/actionlib/html/index.html

Please add all comments by 10am on Friday, July 31st

Present at review:

• List reviewers

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

Stu:

• actionlib doxygen:
  • "The actionlib package is meant to assist ROS users in writing nodes that accomplish specific tasks". Mention that it's long-running tasks.

• Everything is templated on an ActionSpec, but it's not discussed anywhere

• Discuss what feedback is.

Response:
[Vijay] These are all valid points. None of these seem like API changes, but rather, they are documentation updates. We will definitely update the documentation accordingly.

---

Alex Sorokin

I ran into an issue with the robot_actions client. When I call execute from a message callback, it blocks the entire message queue. The action client then doesn't receive any status updates and dies on time out.

The solution that I found is to use multi-threaded spinner:
   ros::MultiThreadedSpinner spinner;
   ros::spin(spinner);

It isn't very nice to require that action users use a multi-threaded spinner. Maybe there are other ways to make sure that the action interface gets its messages. I haven't tested the new API, but a very brief look at the coded hinted that the actionlib would behave the same. Please consider having a test for action client that is executed inside a message callback.

Response
[Vijay] Our sendGoal() call is nonblocking. Thus you can call send goal from a ROS callback, and it will return immediately. However, it sounds like what you really want to do is call sendGoal from within a ROS callback, and block in the callback until the goal completes. This is the same design pattern as any blocking callback in ROS: Your callback should be called from a callback queue other than the global callback queue, and you should spin a new thread to service this new callback queue. If this is unintuitive, then ROS should make it easier to do this. It doesn't make sense to push this functionality into actionlib.

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved

---