Part II:  Creating the Package Skeleton

In Part I of this series, we examined the overall architecture that will be put in place with the development of the ROS package.  It’s time to get our hands dirty and put the theory hypothesis to work!  Accordingly, this post in the series will focus on putting together the skeletal package which will contain the various layers of the described architecture. If you’d like to skip to the chase and download the source to this article, click here.

Prerequisites:

If you went through the excellently written ROS tutorials (you did, didn’t you?), you’re no doubt aware that ROS brings with it a number of helpers to make our lives easier.  Accordingly, we’ll start by using roscreate-pkg to create the ROS package itself followed by placeholder folders for the remainder of the package.

  1. Open a terminal and cd to where you’d like your package to reside.  You’ll need to put the package in a folder which is included in the ROS environment variable $ROS_PACKAGE_PATH.  (You can check this setting by running echo $ROS_PACKAGE_PATH at a terminal.)  If your destination folder isn’t defined in $ROS_PACKAGE_PATH (or a sub-folder), you’ll need to add it via /opt/ros/cturtle/setup.sh (e.g., export ROS_PACKAGE_PATH=/opt/ros/cturtle/stacks:/home/username/folder).
  2. Create your package as follows:
    roscreate-pkg ladar_reporter
  3. Verify that ROS can find the package:
    rospack find ladar_reporter
  4. Build the new ROS package:
    rosmake ladar_reporter
  5. Now that the package has been created and building successfully, create a folder structure under the root of the package as follows:
    • src:  Will contain all the source files of the package.
    • src/core:  Will contain the core elements of the package including, and most importantly, the domain layer.  (See Part I for more information concerning the domain layer.)
    • src/core/message_endpoint_interfaces:  Will contain the message endpoint interfaces but not their concrete implementations.  (Consequently, the domain layer will only have knowledge of the message endpoint interfaces, decoupling it from the messaging middleware.)
    • src/application_services:  Will contain the service layer of the package.  In a nutshell, the service layer coordinates the application workflow.
    • src/message_endpoints:  Will contain the concrete classes for communicating with the ROS messaging middleware.
    • src/ui:  Will contain the UI for interacting with the package.  (This layer is not needed on all packages.)
    • test:  Will contain the test classes of our package.
    • test/core:  Will contain tests for classes within src/core.
    • test/application_services:  Will contain tests for classes within src/application_services.
    • test/message_endpoints:  Will contain tests for classes within src/message_endpoints.
    • test/message_endpoints/test_doubles:  Will contain test doubles (stubs to be exact) for testing the application services and domain layer independently from ROS.
  6. If using an IDE (e.g., eclipse), follow any additional directions at http://www.ros.org/wiki/IDEs to make the new project compatible with your IDE.

And with that, the package skeleton is now in place.  Folders have been added to represent all of the application layers that will come to fruition over the next few posts, as we see the package evolve.  (Typically, folders would only be added as needed, but this post provides a concise means to see how the end product will be structured.)

In Part III of this series in developing a well-designed ROS package, the domain elements will be added to the core layer with unit testing, accordingly.

Enjoy!
Billy McCafferty

Download the source for this article.