On Tue, Jan 25, 2011 at 11:00 AM, Patrick Bouffard
<bouffard@eecs.berkeley.edu> wrote:
> Is there anywhere in the documentation where recommendations are made
> on things such as as to how to advertise topics? I don't mean the
> mechanics of how to code it, that is well documented.

I believe this has been addressed on the list before but I can't find
it.  We should try to get a wiki page or a REP somewhere describing
it.  I believe these principals will be made more clear when we move
toward an official notion of "interfaces" within ROS.  At the moment,
many nodes adhere to unofficial interfaces, which make
interchangeability much  more straightforward.  These interfaces are a
standardized set of topics that nodes providing a particular function
will use.

> Let me give an example. So I know I want node A to publish topic T
> which will be subscribed by node B. Topic T is what I would consider a
> 'primary' topic in that it's the main output of node A and an
> important input for node B, as opposed to some ancillary data or
> something for debugging.
>
> Now when advertising T, I can advertise it with the node A's regular
> node handle, so it gets advertised as (assuming no runtime namespace
> pushdowns) /T, or I can advertise it with the private nodehandle, so
> it gets published as /A/T. Which one of these is the 'preferred' way,
> and why?

If you look through nodes in released stacks, you should in general
see a convergence within the interfaces toward publishing on topic "T"
in the global namespace where T is an appropriate and hopefully
intuitive name that makes remapping easy.

As examples, laser_scaners publish to "scan," and cameras publish
their topics within a grouped namespace "camera" regardless of the
type of laser_scanner or camera in question.  This makes it very easy
to interchange a particular node with one that matches the interface
but has a different internal implementation.  Note: in the camera
case, camera is a namespace used to consolidate topics, but it is NOT
the private namespace.

We try to avoid publishing in the private namespace of a node since
this means the node can never be used without some thought into
remapping/configuration.  Moreover, if you don't remap it for the
publisher it it means you are remapping a subcriber to look inside
another nodes private namespace, which feels fundamentally wrong and
against the principals of anonymous publish-subscribe.

>
> Then, on the other end of that conversation, how do I tell node B what
> to subscribe to? Do I explicitly subscribe to either /T or /A/T,
> depending on the decision made above, or do I do something like
> subscribe to ~input (i.e. /B/input), and require a remapping at
> runtime, a la image_view or the pcl filters? Or do I even make the
> topic to subscribe to configurable via a parameter?
>

Likewise, having B subscribe into it's own (or another) private
namespace is problematic for the same symmetric reasons that it's
inconvenient for A to publish there.  Ideally this input should by
default match the same topic name interface that the publisher is
using.

For example, the laser_scan assembler also uses the topic name "scan."

> Very similar questions could be asked of naming for services and parameters..
>
> I like that there is flexibility but it would be nice if there was a
> conventional way to do this, as well as some rationale as to why it is
> the convention and some guidelines for when to break convention.

The motivating idealized behavior is that in a simple system you
shouldn't need to do remaps to get nodes working together if they were
designed to work together.  In a more complex system, where you, for
example, have 2 laser scanners, remapping will be necessary, but all
places where you have to do that remap will use the same "from"
target, making the launch-file far easier for a human to read.

>
> Maybe something like this already exists on the wiki and I missed it,
> if so just point me there and my apologies. If not this seems like
> something that should perhaps go in an Informational REP.

I like the idea of an informational REP on this.  If nobody else
tackles it I'll try to throw something together when I find the time.

Cheers,
--Jeremy