roscpp/Reviews/2010-01-11_Doc_Review

Reviewer: Patrick

Instructions for doing a doc review

See DocReviewProcess for more instructions

1. Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?
   • Yes - most users of ROS, particularly those interested in high performance. The roscpp overview does a good job of highlighting the most important APIs.
2. Are all of these APIs documented?
   • Yes, but nitpicks under concerns/issues.
3. Do relevant usages have associated tutorials? (you can ignore this if a Stack-level tutorial covers the relevant usage), and are the indexed in the right places?
   • Yes, the fundamentals (topics, services, parameters) are well covered. Nitpicks under concerns/issues.
4. If there are hardware dependencies of the Package, are these documented?
   • N/A
5. Is it clear to an outside user what the roadmap is for the Package?
   • Should link to the ROS roadmap like the rospy page does.
   • Josh: FIXED
6. Is it clear to an outside user what the stability is for the Package?
   • It's implied that roscpp is stable.
7. Are concepts introduced by the Package well illustrated?
   • Yes, the links to ROS concept pages are useful.
8. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
   • N/A
9. Are any mathematical formulas in the Package not covered by papers properly documented?
   • N/A

For each launch file in a Package

1. Is it clear how to run that launch file?
2. Does the launch file start up with no errors when run correctly?
3. Do the Nodes in that launch file correctly use ROS_ERROR/ROS_WARN/ROS_INFO logging levels?

Concerns / issues

Patrick

• Main wiki page
  • The "Compile options" section seems too specific to me to deserve such prominent placement.
    • Josh: FIXED, moved to a separate section in the overview

  • Would be nice if Parameters in the package summary linked directly to Parameter Server.

    • Josh: FIXED
• Tutorials
  • Each tutorial page should link to the next one with next.0.link. I also like having a next link at the bottom of the tutorial to keep the user moving along.
    • Josh: FIXED

  • Methods and class names aren't monospaced 100% of the time, style. Not a big deal.

    • Josh: FIXED I think

  • Maybe "Accessing Private Names from a NodeHandle" should come after "Using Parameters in roscpp" so getParam() is introduced first.

    • Josh: FIXED

  • roscpp_tutorials/Tutorials/Parameters describes the deprecated version of getParam().

    • Josh: FIXED
• Overview

  • Service Connection Headers mentions that they're a feature of both services and topics, which begs the question of how to use them with topics.

    • Josh: You can't currently provide extra header data in topics

  • Parameter Server section also mentions the deprecated getParam() behavior.

    • Josh: FIXED

  • Callbacks and Spinning might give an example of when you would actually want to use a custom callback queue.

    • Josh: FIXED
• Doxygen

  • Consider adding link to ros::param namespace on the main page.

    • Josh: FIXED. Also added ros::names

  • ros::TransportHints is undocumented. It should have main text saying what it is and demonstrating the named parameter idiom, and text for what each parameter method does.

    • Josh: FIXED

  • Detailed description for ros::master::check() seems out of date, overview says you can call it after ros::init().

    • Josh: FIXED (wow, that doc string dated from the Node days)

  • ros::start() could use a description similar to ros::shutdown().

    • Josh: FIXED

  • *Options classes aren't quite completely documented.

    • AdvertiseOptions: No description of init(), create(). No briefs for latch, tracked_object.

    • AdvertiseServiceOptions: No class description. No description of create(). No brief for tracked_object.

    • etc.
    • Josh: FIXED

  • No class description of CallbackQueueInterface. CallbackQueue has undocumented functions.

    • Josh: FIXED

  • No documentation of SubscriptionMessageHelper. It's pretty internal, but I've been advised to subclass it...

    • Josh: FIXED... I've explicitly marked those classes as not API stable though, since they're going to have to change significantly to support both the new serialization API and messages that don't inherit from Message

Conclusion

Patrick

Overall the documentation is really good. The tutorials and overview give a beginning user plenty to go on. A lot of my nitpicks are that the dustier corners of roscpp aren't exhaustively documented, which isn't critical.