Most likely this is where you write your business logic / algorithms completely ROS-agnostic (so no use of ROS, its datastructures or any of its algorithms) and then add a relatively thin layer that adds ROS compatibility.
A concrete example: let's say you have some audio processing code for speech recognition. You put this in a libMySpeechProcessor
. That library is completely stand-alone, does not make use of any part of ROS anywhere. Now to be able to use that in ROS, you create a ROS node that advertises a service processAudio(..)
, performs any initialisation necessary for your speech recognition engine and then makes use of the functionality provided by libMySpeechProcessor
in the callback associated with the service server.
Note that libMySpeechProcessor
does not have any dependencies on ROS.
The main advantage of this is that your library can now be used on its own, without someone wanting to use your speech processor having to install ROS (or Linux, perhaps it is even Windows compatible like this).
Note also that this is not a new concept, or something specific to ROS: in general it is always a good idea to avoid dependencies as much as possible and to not tie yourself to one specific framework or library.