Repo Structure

[AlexReimann]

Looking at the current structure and integrating a cpp example into it, maybe we should think about the structure a bit more.

Some points which I actually would like:

• Minimal C++ and python packages example
  • Also allows to specify what the minimum should be (e.g. has tests)
• Separate Msgs package example
• "Maximal" C++ package
  • Node and Nodelet
  • Pub / sub
  • Action server
  • Service
  • Dynamic reconfigure
  • Example of separating ROS from non-ROS stuff (extra package?)
  • All kinds of test examples
• "Maximal" Python package
• Mixed Python - C++ example
  • Probably mixed minimal
  • Maybe not enough time for that while I'm here though..

[asmodehn]

While all this would definitely be interesting, I think we should focus first on having ONE package properly setup :-)

I would focus on the maximal ROS one (include as much as possible basic ROS stuff), but still trim the fat (reduce software bloat), and extracting the bare minimum from it should be quite simple afterwards.

Also mixing python and C can be done in many different ways, so maybe it s not worth worrying about that now and make a separate package for different language ?

In this maximal (python) package, comparing with your list, I currently aim for :

• node (NO nodelet, there isn't in python yet sadly)
• pub / sub
• NO action server : people usually don't understand topics and services enough to use them properly, so no point adding an extra layer of complexity (that isn't useful in high-level/relatively high latency/python anyway).
• service
• NO dynamic reconfigure (yet, but it would be useful I think... might do it eventually)
• example of separating ROS and non-ROS (the python module is ROS independent and can be used from command line directly)
• python unittest/nose tests and rostests

How about starting wiht the same in C and add the things that are necessary for C ( I am thinking about nodelet especially. Not really convinced about Action Server...)

[asmodehn]

We could also use https://github.com/ethz-asl/ros_best_practices/tree/master/ros_package_template as a reference...

[asmodehn]

After a quick chat, a few decisions :

• always separate message packages. make things simpler, and is the de-facto standard. (see separate msgs package #6)
• separate C ROS package, interfacing with python via ROS messaging ( the usual situation ).

[AlexReimann]

Looking at this discussion and my multi-threaded implementation, this is not that much trimmed down.

I guess I could cut down by removing one of the publishers in the nodelet. The "internal" publisher can be subscribed to externally anyways and maybe just makes things confusing.
Besides that the discussed is pretty much done from my side (if it is not in a separate issue).