image_proc/Reviews/01-04-2010_Doc_Review

Reviewer: Radu

Instructions for doing a doc review

See DocReviewProcess for more instructions

• Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?

  Not sure if this question is appropriate for image_proc.

• Are all of these APIs documented?

  The package's API is not entirely documented. Most functions do not have a clear description or usage example.

• 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.

• If there are hardware dependencies of the Package, are these documented?

  There are no hardware dependencies.

• Is it clear to an outside user what the roadmap is for the Package?

  If by roadmap we refer to the usage/dependency graph, then yes, it is clear.

• Is it clear to an outside user what the stability is for the Package?

  Yes, the package status is marked as unreviewed.

• Are concepts introduced by the Package well illustrated?

  Yes.

• Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?

  Does not apply.

• Are any mathematical formulas in the Package not covered by papers properly documented?

  Does not apply.

For each launch file in a Package

• Is it clear how to run that launch file?

  There are no lunch files, however, it is clear how to start the nodes.

• Does the launch file start up with no errors when run correctly?

Yes.

• Do the Nodes in that launch file correctly use ROS_ERROR/ROS_WARN/ROS_INFO logging levels?

  • While the node uses the ROS_XXX primitives, the ImageData object does not.

Concerns / issues

• Not sure if this matters here, but the code API should be better documented.
• I am not sure if we should mention PR2* related stuff in the mini tutorial, or if we _really_ need to, we could just say "i.e., for the PR2 robot" or something.
• Is the package supposed to be general? If so, why do we have so many VIDERE_* related stuff in it?
• all PRINTF statements should be changed to ROS_XXX or removed.

• The source file are a bit of a mess There is a lot of commented code, #if 0, etc, which should be cleaned up before release.

• There is no documentation on the type of interpolation used (though this is specified in the source file, it doesn't pop up using Doxygen as the comments are not formatted).

• in src/proc/image.cpp there are a lot of methods defined for a class which does not exist anymore (StereoData). This should be cleaned up.

• the node itself is cleanly written, however a few lines of Doxygen comments wouldn't hurt

• PS: I don't like the "cam" namespace for ImageData. It's just not informative enough.

Conclusion

• More of an all-round review than a DOC review, the package looks good and it is easy to use. However, there are a few outstanding issues (see above) that need to be resolved before an official release in my opinion.

• PS: I discovered that image_proc does not warn when the intrinsic camera parameters are wrong. An use case discovered today was ticketed at: https://code.ros.org/trac/ros-pkg/ticket/3502