Nodelet version of the octomap server

[GoogleCodeExporter]

Hi there!

I attached a patch, which adds a nodelet version of the octomap server.
The changes are minimal.
Only important change to files outside octomap_server_nodelet.cpp is the 
addition of passing a node handle to the OctomapServer class and also using the 
same handle for retrieving parameters.
This is necessary, because otherwise topic and parameter remappings will not 
work.

Marcus

Original issue reported on code.google.com by i...@marcusliebhardt.de on 19 Nov 2012 at 3:23

Attachments:

• nodelet.patch

[GoogleCodeExporter]

Fixed in trunk (Rev. 3625), thanks for your contribution! I still need to apply 
it to the groovy-devel branch, I'll close the issue then.

Original comment by h...@informatik.uni-freiburg.de on 21 Nov 2012 at 5:03

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Applied to  the groovy version to be released (0.4.8). However, I noticed that 
the patch changes the topic names, all topics get moved into the local 
namespace (since both node handles use "~" from the default parameter). I 
removed this for the global NodeHandle since some topics need to be in "/". 

Is it necessary to also expose that as a parameter to the nodelet? Then two 
node handles need to be passed to the constructor.

Original comment by Armin0Ho...@gmail.com on 8 Jan 2013 at 4:25

[GoogleCodeExporter]

AFAIK, one should avoid hard-coding absolute namespaces (starting with "/"), 
because one can't be sure that everybody is using the same topic names, even 
when some are commonly used. Topic names can easily be adjusted to one's needs 
by remappings in the launch file.

Handling namespace and node handles are a bit more complicated when using 
nodelets, since they get loaded by the nodelet manager. So, in order to answer 
your question I would need to test your changes first. Which version should I 
download?

Original comment by i...@marcusliebhardt.de on 8 Jan 2013 at 11:53

[GoogleCodeExporter]

It's not hard-coded but uses the default no-namespace constructor of 
NodeHandles, which results in a global namespace unless remapped. I see the 
global namespace as an essential part of anonymous pub/sub in ROS. If each 
topic is only in a private namespace, then each publisher needs to know exactly 
what subscriber it expects, or one needs to remap topics every time. It should 
be possible, however, to swap out similar nodes, e.g. replacing one publisher 
with another without the subscriber caring about the actual implementation.

To this end octomap_server has some topics in a global namespace (NodeHandle 
m_nh) and other less important ones (debug, parameters) in the private one 
(NodeHandle private_nh). This should not change, otherwise other people's code 
and launch files will break because suddenly topics are different.

The changes back to the old behavior (while preserving the constructor 
parameter for the private NodeHandle) are in the latest commits here:
ROS groovy: 
https://alufr-ros-pkg.googlecode.com/svn/branches/octomap_stacks-groovy-devel/oc
tomap_mapping/
ROS fuerte: 
http://alufr-ros-pkg.googlecode.com/svn/trunk/octomap_stacks/octomap_mapping/

If the nodelet also needs access to the global NodeHandle, then we simply need 
another parameter in the constructor.

Original comment by ar.hrng on 9 Jan 2013 at 11:24

[GoogleCodeExporter]

Following up on the issue about not being able to load the nodelet:
It's a bit weird. The configuration (macro call, plugin info export etc.) looks 
fine. However, the nodelet can't be found (e.g. roslaunch throws errors, 
`rospack plugins --attrib=plugin nodelet` doesn't list the plufin).

The package path is set correctly and even rosmake runs through without errors. 
`roscd` and `rospack find` all work, but `rospack profile` hides the whole 
stack. 

Currently, I have no clue what's causing this problem.

PS: I have tested octomap_server from the `octomap_stacks-groovy-devel` branch.

Original comment by i...@marcusliebhardt.de on 12 Jun 2013 at 10:11

[GoogleCodeExporter]

Closing here, issue continues on GitHub:
https://github.com/OctoMap/octomap_mapping/issues/1

Original comment by ar.hrng on 7 Nov 2013 at 10:44

• Changed state: Duplicate