navfn/Reviews/2009-10-06 Doc Review

Reviewer:

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, though perhaps making this a little more explicit in the package documentation would help.
2. Are all of these APIs documented?
   • Yes.
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?
   • No tutorials beyond those for the navigation system as a whole, but that is OK. The end user is not expected to need to interact with NavFN or NavFNRos directly.
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?
   • Stack level roadmap is OK, only think I might like to see as a user in a package roadmap is navFN cleanup / debugging of A*.
6. Is it clear to an outside user what the stability is for the Package?
   • Yes, it is clearly listed in a section for each package component.
7. Are concepts introduced by the Package well illustrated?
   • The costmap computation would make for a pretty picture, but full documentation for NavFN is probably where this should go, and that is a project for the future. Otherwise I don't think any illustrations are required.
8. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
   • I don't think there is anything that needs to go here, perhaps in NavFN documentation when it exists.
9. Are any mathematical formulas in the Package not covered by papers properly documented?
   • N/A for NavFNROS, NavFN is not being documented at the moment

For each launch file in a Package

• N/A

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

• Generic C++ ROS Wrappers section should not be at the same level as NavfnROS and NavFN. It belongs under NavfnROS, and should probably be made specific as in:
  • "NavfnROS is a ROS Wrapper which means it is a C++ class that exposes a ROS interface for the underlying library NavFN. ROS wrappers read their configuration from the Parameter Server and often publish information on Topics using a namespace passed to them on construction."

    As a general comment it seems like "C++ ROS Wrappers" are an instance of a common pattern post NodeHandle that we have not formalized anywhere. They're kind of like node components, you can mix as many of them as you want together into a single node, but each component is self contained and performs the same sort of functionality a full node would. If there were a name for this pattern, say "node mixin" (note, this is not really a great name, but I'm using it for illustration purposes), then this whole section could be reduced to something like:

    • "NavfnROS is a wrapper for NavFN which exposes its functionality as a node mixin."

• I talked to Ken about formailizing this on a ROS level and he felt that since the design pattern is only being used in the navigation stack, that it should only be formalized at the stack level. So, I've added the navigation/ROS_Wrappers page so that I can remove all of the "C++ ROS Wrappers" stuff.

• The Overview section should make it clear that this package consists of two components, NavfnROS and NavFN. This will make organization of the rest of the page clearer, especially once "C++ ROS Wrappers" has been removed.
  • Tried to make this clear
• NavFN docs: Thanks for adding this. One minor change I'd like:

  • "Sets the start position for the planner. Note: the navigation function is computed from goal to start." -> "Sets the start position for the planner. Note: the navigation cost field computed gives the cost to get to a given point from the goal, not from the start. "

    • Changed... might take a little to update since its Doxygen

Minor edits:

• "The navigation function is computed with Dijkstra" in Package Summary should probably be "The navigation function is computed with Dijkstra's algorithm". I tried to change this in the wiki, but I think it's being pulled from the code comments with the TOC(4) command.

  • Its actually pulled from the manifest with the PackageHeader macro, I've updated it, but it might take an hour or so to make it to the wiki

• NavFnROS: "hereon" -> "here on" (already edited in wiki, this may be an acceptable composite form, but it didn't scan well for me as I was reading)

  • Fair enough... works for me

Conclusion

Things are looking much better. There are a few minor cleanup issues, but nothing that should take very long.