Revision history [back]

If you build something as a nodelet - you should be able to run it in two ways

1. As part of a group of nodelets under a Nodelet Manager
2. As a standalone node

Once I make a nodelet, reproducing it as a node is redundant.

If instead, you wish the classes in your library to be more widely available to different systems, then jbohren's method is a good way of making that possible. However, I don't think that's strictly necessary. A library in ros can have two api's:

1. a c++ api (like your regular old standard library)
2. a ros comms api (msgs, srvs and actions)

If you expose your interface via ros comms through a nodelet, then you don't need to expose a c++ api simultaneously. And if you're using nodelets, you don't have to worry about this communciation being significantly slower. Mixing in a c++ api doesn't provide any appreciable benefit.

Sometimes however you need to provide only a c++ api to clients (i.e. non ros users). Then you need to get rid of the ros components completely. We do that occasionally - and if we want to use the same library in a ros system, we create a separate nodelet library which wraps the c++ library. Nodelet subscriber callbacks can utilise the c++ api directly, whereas publishers can be triggered by mechanisms like signals (sigslots) coming from the c++ library.

If you build something as a nodelet - you should be able to run it in two ways

1. As part of a group of nodelets under a Nodelet Manager
2. As a standalone node

Once I make a nodelet, reproducing it as a node is redundant.

<launch>
    <node pkg="nodelet" type="nodelet" name="navi_base" args="standalone goo/GooNodelet">
        <rosparam file="$(find goo)/resources/yaml/navi_base.yaml" command="load" />
    </node>
</launch>

If instead, you wish the classes in your library to be more widely available to different systems, then jbohren's method is a good way of making that possible. However, I don't think that's strictly necessary. A library in ros can have two api's:

1. a c++ api (like your regular old standard library)
2. a ros comms api (msgs, srvs and actions)

If you expose your interface via ros comms through a nodelet, then you don't need to expose a c++ api simultaneously. And if you're using nodelets, you don't have to worry about this communciation being significantly slower. Mixing in a c++ api doesn't provide any appreciable benefit.

Sometimes however you need to provide only a c++ api to clients (i.e. non ros users). Then you need to get rid of the ros components completely. We do that occasionally - and if we want to use the same library in a ros system, we create a separate nodelet library which wraps the c++ library. Nodelet subscriber callbacks can utilise the c++ api directly, whereas publishers can be triggered by mechanisms like signals (sigslots) coming from the c++ library.

If you build something as a nodelet - you should be able to run it in two ways

1. As part of a group of nodelets under a Nodelet Manager
2. As a standalone node

Once I make a nodelet, reproducing it as a node is redundant. Some history: nodelets came after nodes once they realised there was a need. Their implementation (nodelets can detect when communications are intra or inter and behave accordingly) was such that the node actually became superflous. But we still have nodes because people are familiar them. them and they are a little easier to code.

An example standalone nodelet launcher:

<launch>
    <node pkg="nodelet" type="nodelet" name="navi_base" args="standalone goo/GooNodelet">
        <rosparam file="$(find goo)/resources/yaml/navi_base.yaml" command="load" />
    </node>
</launch>

If instead, you wish the classes in your library to be more widely available to different systems, then jbohren's method is a good way of making that possible. However, I don't think that's strictly necessary. A library in ros can have two api's:

1. a c++ api (like your regular old standard library)
2. a ros comms api (msgs, srvs and actions)

If you expose your interface via ros comms through a nodelet, then you don't need to expose a c++ api simultaneously. And if you're using nodelets, you don't have to worry about this communciation being significantly slower. Mixing in a c++ api doesn't provide any appreciable benefit.

Sometimes however you need to provide only a c++ api to clients (i.e. non ros users). Then you need to get rid of the ros components completely. We do that occasionally - and if we want to use the same library in a ros system, we create a separate nodelet library which wraps the c++ library. Nodelet subscriber callbacks can utilise the c++ api directly, whereas publishers can be triggered by mechanisms like signals (sigslots) coming from the c++ library.

If you build something as a nodelet - you should be able to run it in two ways

1. As part of a group of nodelets under a Nodelet Manager
2. As a standalone node

Once I make a nodelet, reproducing it as a node is redundant. Some history: nodelets came after nodes once they realised there was a need. Their implementation (nodelets can detect when communications are intra or inter and behave accordingly) was such that the node actually became superflous. But we still have nodes because people are familiar with them and they are a little easier to code.

An example standalone nodelet launcher:

<launch>
    <node pkg="nodelet" type="nodelet" name="navi_base" args="standalone goo/GooNodelet">
        <rosparam file="$(find goo)/resources/yaml/navi_base.yaml" command="load" />
    </node>
</launch>

If instead, you wish the classes in your library to be more widely available to different systems, then jbohren's method is a good way of making that possible. However, I don't think that's strictly necessary. A library in ros can have two api's:

1. a c++ api (like your regular old standard library)
2. a ros comms api (msgs, srvs and actions)

If you expose your interface via ros comms through a nodelet, then you don't need to expose a c++ api simultaneously. And if you're using nodelets, you don't have to worry about this communciation being significantly slower. Mixing in a c++ api doesn't provide any appreciable benefit.

Sometimes however you need to provide only a c++ api to clients (i.e. non ros users). Then you need to get rid of the ros components completely. We do that occasionally - and if we want to use the same library in a ros system, we create a separate nodelet library which wraps the c++ library. Nodelet subscriber callbacks can utilise the c++ api directly, whereas publishers can be triggered by mechanisms like signals (sigslots) coming from the c++ library.